[ntp:questions] Ntpd in uninterruptible sleep?

A C agcarver+ntp at acarver.net
Sun Oct 23 23:19:30 UTC 2011


On 10/23/2011 16:06, unruh wrote:
> On 2011-10-23, A C<agcarver+ntp at acarver.net>  wrote:
>> A continuation of my debugging ntpd on a sparc system running NetBSD.
>> First, using -N results in a system lockup after a period of time if I
>> am polling ntpd remotely with ntpq.  I removed the -N option from
>> startup and the system stayed stable even when querying at 5 second
>> intervals.
>>
>> However, I just ran into a new problem.  Here's the output of ps ax for
>> the ntpd entry:
>>
>> 22887 ?     Ds     20:17.58 /usr/sbin/ntpd
>>
>>
>> Uninterruptible sleep?  The daemon is indeed asleep because it stopped
>> responding to my ntpq queries but this time the system stayed up.  I
>> suspect it was this same sleep that occurred in the other condition but
>> the high priority locked up the machine.  I was able to kill and restart
>> ntpd without having to fully reboot.  All other processes were still
>> running normally but slowly (see below).
>>
>> More interesting is that the cpu was pegged until I was able to kill and
>> restart ntpd.  Most of the cpu was devoted to ntpd during this locked up
>> period.  Simple things like typing at the console were difficult.  It
>> would take a few seconds for a keypress to register on the screen.  Once
>> ntpd was restarted the system responded normally and the cpu usage
>> dropped to normal levels.
>>
>> This is still version 4.2.6p3.  I should probably go ahead and compile
>> the most recently released version but I'm at a loss to understand why
>> it happened.
>
> Is there some problem with your ethernet card? Is ntpd polling and
> unresponsive card like mad? Ie, is hardware a problem?

The network interface (AUI with a 10BT transceiver, Lance Ethernet) was 
up and running the entire time.  I had xclock running on the system with 
the display exported to another machine and I also had an ssh session in 
an xterm up and running.  Both of those continued to function (albeit 
slowly) while ntpd was stuck in that sleep state.  I actually used the 
ssh-in-xterm session to kill and restart ntpd.  There was no significant 
polling on the interface (activity LEDs showed normal behavior).


More information about the questions mailing list