sleep(3) sometimes too sleepy on FreeBSD 8.0?
peterjeremy at acm.org
Wed Feb 24 07:54:02 UTC 2010
Updates following some off-line discussions and debugging with John on
IRC. I've cc'd gshapiro@ because the problem appears to be sendmail,
rather than the FreeBSD kernel.
On 2010-Feb-23 12:35:22 +1100, John Marshall <john.marshall at riverwillow.com.au> wrote:
>Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2
Note that this is stock ISC sendmail, not the sendmail in either the
base system or the port.
>I posted about this in comp.mail.sendmail and was told...
>> sleep() should be one of these calls:
>> if (njobs == 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLEEP_TIME)
>> else if (WorkGrp[wgrp].wg_lowqintvl <= 0)
>> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME);
Whilst it's true that the code calls sleep(), it's not calling
sleep(3) in the FreeBSD libc. Instead it's calling a sleep() defined
in libsm/clock.c - which is a horrible maze of #ifdefs.
John has pre-processed that code and the result it at:
At a quick look, the code is broken: sm_seteventm() generates a
one-off timer using setitimer(2), which will send SIGALRM when it
expires. sm_releasesignal() then unblocks SIGALRM. In theory, the
SIGALRM could be delivered anywhere after the (!SmSleepDone) test and
before pause() is called - in which case, the signal is lost and
pause() will sleep forever.
On 2010-Feb-24 08:13:06 +1100, John Marshall <john.marshall at riverwillow.com.au> wrote:
>My ktrace file was created with 'ktrace -g 48501'. I have the result of
>'kdump -R -p 48504' available at:
The syscall pattern near the end of this file is significantly different
from that elsewhere in the file - with gettimeofday(), sigprocmask() and
sigsuspend() looping fairly rapidly. Interestingly, sigsuspend() is
returning EINTR but no signal is reported. I'm not sure what could
This syscall pattern looks like the while() loop in sendmail's sleep(),
though it does appear that the loop is exited on that occasion but not
on the following occasion (though the reason for this behaviour is
Overall, it appears that there is a race condition in sendmail and
something in the 8.0 signal handling appears to make this race easier
Going back to the original clock.c source code, the other thing that
is obvious is the HAVE_NANOSLEEP block - if this was active, sleep()
would call nanosleep(2) and the whole signal mess would be avoided.
It's not clear when that code was added but clock.c has not been
touched for many years. In the sendmail in FreeBSD-8.0, there is no
other reference to HAVE_NANOSLEEP within sendmail. sendmail 8.14.4
(in 8-STABLE) has HAVE_NANOSLEEP enabled on Solaris 11 only.
Is there any reason why HAVE_NANOSLEEP is not defined for FreeBSD?
Looking back through the commit logs, nanosleep(2) was implemented in
sys/kern/kern_time.c v1.23 on Thu May 8 14:16:25 1997 UTC - that's
just before RELENG_2_2.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100224/f1b8324e/attachment.pgp
More information about the freebsd-stable