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.marsh...@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.marsh...@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.
> > 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 > cause this. Is this 8.0-RELEASE ? Please note that kern_sigsuspend() code was changed in HEAD/RELENG_8 after 8.0 release. > > 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 > unclear).
pgpfcemoa5kXU.pgp
Description: PGP signature
