[ntp:questions] Re: ACTS - too many recvbufs allocated (40) (Correct the Version of ntp-dev)

Danny Mayer mayer at gis.net
Fri Feb 11 02:47:45 UTC 2005



Ronan also pointed out something related to this that I don't remember seeing
but then I tend to stay away from clock issues.

I'll try and get something fixed tonight or tomorrow so I can test.

Does this mean that rackety is no longer like molasses in winter?


At 08:46 PM 2/10/2005, David L. Mills wrote:
>FreeBSD rackety.udel.edu is currently victim of the bug. It replaced the 
>old SunOS IPC in service for 16 years. You have the keys to the kingdom.
>mayer at gis.net wrote:
>>----- Original Message Follows -----
>>> >> to:
>>> >>          rb->recv_length =
>>> >>              read(fd, (char *)&rb->recv_space, (unsigned)i);
>>> >>
>>> >>          if (rb->recv_length <= 0 || errno != 0)
>>> >>          {
>>> >>                  netsyslog(LOG_ERR, "clock read fd %d: %m", fd);
>>> >>                  freerecvbuf(rb);
>>> >>                  goto select_again;
>>> >>          }
>>> >>
>>> >> This should take care of the problem. I will put a better fix into
>>> >> sources over the next few days.
>>> >That addresses the symptom rather than the cause, which is a hangup
>>> >owing to carrier dropping.  With the above change in place, I'd
>>> >a continuous stream of "clock read" messages, CPU maxed, and no
>>> >input will happen because "goto select_again" picks up the error
>>> >each time round and never does anything else.
>>>Yes, this happens (100% proc consumed, infinite select loop, no other 
>>>input) , as I wrote in some of my previous comments.
>>Oh, I missed that. I have nowhere to test this. Do you know what the
>>error is? I'll try and take another look at it.
>questions mailing list
>questions at lists.ntp.isc.org

More information about the questions mailing list