On 10/24/2011 14:33, Chuck Swiger wrote:
On Oct 24, 2011, at 2:26 PM, A C wrote:
If ntpd crashes, you should get a coredump which you can debug (assuming you've
setup the coredumpsize limit to permit this) and perhaps a syslog message about
a SIGSEGV, SIGBUS, or whatever.
Not if it locks the system up entirely (as in I couldn't even break out of the
kernel) which is what had been happening. Turning off the priority on ntpd
(eliminating the use of the -N flag) seems to avoid the system lock up issue
but doesn't eliminate the ntpd lockup.
That sounds somewhat like an OS bug, where running at very high priority might
livelock the system and prevent it from servicing network traffic or
interrupts. You haven't mentioned which version of NetBSD you are running;
it's possible that it's a known issue which has since been fixed.
Or it could just be something else in the H/W getting flakey...
NetBSD 5.1 (most recent) but the hardware runs fine. In fact without
the high priority everything else on the system worked. I had gpsd
running in the background reading the GPS and servicing data requests
even though ntpd was stuck.
The process just sat there yesterday not doing anything and bogging the machine
down. The process itself doesn't die, there's no core to dump (yet), it just
sits and sits and sits...
This case should be debuggable-- you can to use gdb to attach to the process
and see where it is, or fire off ptrace against it.
I'll try it again when it happens. It was hard to do last time because
the system was completely unresponsive. This time, now that I know
things will still function, I might get some more useful data.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
