On 10/16/2011 12:56, Dave Hart wrote:
On Sun, Oct 16, 2011 at 19:30, A C<[email protected]> wrote:
I'm still trying to
debug a system lockup that may be related to ntpd when it is being polled
for peer status by ntpq from a remote host. I'll probably be posting about
that in a few days though the short summary is that polling ntpd once every
five seconds from a remote machine (using ntpq) caused the ntpd system to
completely freeze after about 20 hours. I stopped the ntpq polling and so
far the machine has been up for a week without a problem.
In that situation, I'd ensure ntpd is not running with elevated
priority. It's conceivable ntpd could be to blame for locking up a
system when it is run at higher priority than something the system
needs, if it were to go nuts and consume a CPU/core. That would be
unusual and a bug. If, on the other hand, you reproduce the system
lockup with ntpd operating at default priority, you can safely point
the finger away from ntpd, IMO.
It is currently using the high priority -N flag when starting up. I'm
going to let it sit for some time before restarting (for flag3 testing)
at which point I'll remove the -N flag from startup and see if polling
kills it. The last backtrace that I did when the system locked up
showed the processor was inside ntpd at the time of the lockup. Where
exactly I couldn't tell you but it was in there and the system was
servicing a serial port interrupt at that same moment (probably for the
PPS driver).
If it stays up through Wednesday I'll know it was the polling that
eventually tripped up the system so I'll have to test again without
priority.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
