sleep(3) sometimes too sleepy on FreeBSD 8.0?

Kostik Belousov kostikbel at gmail.com
Wed Feb 24 12:20:56 UTC 2010


On Wed, Feb 24, 2010 at 03:44:41AM -0800, Jeremy Chadwick wrote:
> On Wed, Feb 24, 2010 at 01:21:39PM +0200, Kostik Belousov wrote:
> > On Wed, Feb 24, 2010 at 06:53:59PM +1100, Peter Jeremy wrote:
> > > 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)
> > > >>                 sleep(MIN_SLEEP_TIME);
> > > >>         else if (WorkGrp[wgrp].wg_lowqintvl <= 0)
> > > >>                 sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME);
> > > >>         else
> > > >>                 sleep(WorkGrp[wgrp].wg_lowqintvl);
> > > 
> > > 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:
> > > http://www.riverwillow.net.au/~john/sm/clock.preprocessed
> > > 
> > > 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:
> > > >
> > > > <http://www.riverwillow.net.au/~john/8_0/rwsrv04_201002240725.kdump.gz>
> > I get 'kdump: data too short' on RELENG_8/i386.
> 
> Is the OP's machine amd64?

No, apparently, the this is indeed output of kdump, as advertised.
It was me who misinterpreted it as ktrace.

Regarding sigsuspend() returning EINTR without delivering any signal,
could it be that the sendmail process was debugged ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100224/7d169f06/attachment.pgp


More information about the freebsd-stable mailing list