Subject: massive use of alarm(0) in imapd

From: Phil Chambers <[email-masked]>
Date: Fri, 30 Jun 2000 15:44:56 +0100 (GMT Daylight Time)

I have just built and installed IMAP-4.7c under IRIX-6.5 (make sg6).  I have only 
unixdriver, dummydriver and auth_md5 in linkage.(c/h) and am using the Berkley 
format for mailboxes.  I had been using a much older version and we were hitting 
problems with disc throughput, so I wanted to look for any signs of a reduction in 
disc read/write activity with the new version.

I ran "par" (IRIX truss-like tool) to monitor system calls and found a very 
surprising use of alarm(0) calls which I cannot trace in the code.  I would 
appreciate an explanation if anyone can provide one.  The trace below my signature 
shows the activity after LOGOUT.

The LOGOUT command is picked up in imapd.c and the sigproc() and sigaction() calls 
come from the server_init() call.  The close(6), fcntl(5), close(5) and unlink() 
come from unix_abort() (via unix_close() via mail_close()).  Then there are 3840 
or so alarm(0) calls which I cannot see any reason for before the write(1, "* 
BYE..) call back in imapd.c.  These alarm(0) calls are not evident in a 
corresponding trace of the old code.

I would welcome help in identifying this as if it is a bug I would like to fix it 
before putting the new code into service.

Phil.
---------------------------------------
Phil Chambers ([email-masked])
University of Exeter

30950mS[  0]         imap4xd(5053720): read(0, 0xfb46d20, 4096)
49095mS[  0]         imap4xd(5053720): END-read(0, "A00058 LOGOUT\r\n", 4096) = 15
49095mS[  0]         imap4xd(5053720): alarm(0) = 881
49095mS[  0]         imap4xd(5053720): alarm(0) = 0
49095mS[  0]         imap4xd(5053720): getpeername(0, {sin_family=AF_INET, sin_port=3148, sin_addr=144.173.7.151}, IN:16) OK
49095mS[  0]         imap4xd(5053720): sigprocmask(SIG_NOP, 0, [<none>]) OK
49095mS[  0]         imap4xd(5053720): sigaction(SIGALRM, {flags=0 handler=SIG_IGN mask=[<none>]}, {flags=0 handler=0x40e4e0 mask=[<none>]}) OK
49095mS[  0]         imap4xd(5053720): sigprocmask(SIG_NOP, 0, [<none>]) OK
49095mS[  0]         imap4xd(5053720): sigaction(SIGUSR2, {flags=0 handler=SIG_IGN mask=[<none>]}, {flags=0 handler=0x40e670 mask=[<none>]}) OK
49095mS[  0]         imap4xd(5053720): sigprocmask(SIG_NOP, 0, [<none>]) OK
49095mS[  0]         imap4xd(5053720): sigaction(SIGHUP, {flags=0 handler=SIG_IGN mask=[<none>]}, {flags=0 handler=0x40e800 mask=[<none>]}) OK
49095mS[  0]         imap4xd(5053720): sigprocmask(SIG_NOP, 0, [<none>]) OK
49095mS[  0]         imap4xd(5053720): sigaction(SIGTERM, {flags=0 handler=SIG_IGN mask=[<none>]}, {flags=0 handler=0x40e950 mask=[<none>]}) OK
49095mS[  0]         imap4xd(5053720): close(6) OK
49095mS[  0]         imap4xd(5053720): fcntl(5, F_SETBSDLKW, {type=F_UNLCK, whence=SEEK_SET, start=32, len=1131741474682044416}) OK
49096mS[  0]         imap4xd(5053720): close(5) OK
49096mS[  0]         imap4xd(5053720): unlink("/tmp/.b2.1a4c02")
49126mS[  0]         imap4xd(5053720): END-unlink() OK
49126mS[  0]         imap4xd(5053720): alarm(0) = 0
****  about 3840 identical alarm(0) calls deleted from the log here ****
49382mS[  0]         imap4xd(5053720): alarm(0) = 0
49383mS[  0]         imap4xd(5053720): time() = 962287837
49383mS[  0]         imap4xd(5053720): write(1, "* BYE hermes IMAP4rev1 server ", 82) = 82
49383mS[  0]         imap4xd(5053720): time() = 962287837
49383mS[  0]         imap4xd(5053720): getpid() = 5053720, ppid=316
49383mS[  0]         imap4xd(5053720): putmsg(4, 0x7fff1558, 0x7fff1564, 0) = 0
49383mS[  0]         imap4xd(5053720): prctl(PR_LASTSHEXIT) = 1
49383mS[  0]         imap4xd(5053720): exit(0)

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Fri, 30 Jun 2000 13:01:52 -0700 (PDT)

It is not a bug, although it is unfortunate.

The problem is that the c-client library has to guard against alarms happening
in certain sensitive functions such as malloc().  This isn't an issue in
imapd, but it is very much an issue in Pine.  That nice busy spinner in Pine
is triggered by an alarm, and massive problems happen if that happens while a
sensitive function is in progress (all Pine's malloc() requests go through the
c-client library).

The easiest way to see if an alarm is in progress is just to do an alarm(0)
and see if the return value indicated that one was in progress.

Since imap-2000 is in release candidate stage, I strongly urge you to consider
using imap-2000 instead of imap-4.7c. Besides new features, imap-2000 has some
additional bugfixes to the handling of UNIX format mailboxes.
	ftp://ftp.cac.washington.edu/mail/imap-2000.BETA.tar.Z

I am curious why you felt that it was necessary to disable the other drivers
and authenticators in the linkage.  You're not gaining much, if anything, by
doing so.