Hello All,
I've run across my first case of the tight looping problem in
dbmail-imapd today. I am running dbmail 1.1 with Jesse's big patch from
a few days back. Here's the appropriate slice of my process table:
USER PID %CPU %MEM VSZ RSS STAT START TIME COMMAND
root 31160 0.0 0.1 3064 744 S Mar11 0:00
/usr/local/dbmail/bin/dbmail-imapd
root 7362 0.0 0.1 3168 864 S Mar11 0:00 \_
/usr/local/dbmail/bin/dbmail-imapd
root 7363 0.0 0.2 4576 1848 S Mar11 2:54 \_
/usr/local/dbmail/bin/dbmail-imapd
root 7364 0.0 0.3 5920 2392 S Mar11 3:39 \_
/usr/local/dbmail/bin/dbmail-imapd
root 7371 0.0 0.3 4696 1976 S Mar11 2:29 \_
/usr/local/dbmail/bin/dbmail-imapd
root 10485 76.6 0.3 5640 1920 R Mar18 8468:44 \_
/usr/local/dbmail/bin/dbmail-imapd
root 23125 0.2 0.2 5616 1880 R Mar25 4:19 \_
/usr/local/dbmail/bin/dbmail-imapd
root 7892 0.0 0.2 4736 1464 S Mar11 0:00 stunnel -d 993 -p
./server.pem -r localhost:imap
(A quick note here, the stunnel command show allows you to provide imaps
with dbmail if you so desire.)
I attached strace to 10485, but there was no output, whatever loop it is
in, it's not making any system calls. While this CPU eating loop was
happening, dbmail-imapd became unresponsive and would block when you
tried to retrieve a message, but as soon as that process was killed, it
continued to work as normal. When I did kill the process, it was never
reaped, it's still sitting <defunct> in my process table, eight hours later.
Here's the last bit of logging from that process:
Mar 20 00:15:09 fork dbmail/imap4d[10485]: PerformChildTask(): incoming
connection from [192.168.111.205]
Mar 20 00:15:09 fork dbmail/imap4d[10485]: COMMAND: [1 authenticate login]
Mar 20 00:15:09 fork dbmail/imap4d[10485]: IMAPD [PID 10485]: user (id
1, name blake) login accepted @ 2003-03-20 00:15:09^M
Mar 20 00:15:10 fork dbmail/imap4d[10485]: COMMAND: [2 select "dbmail"]
Mar 20 00:15:10 fork dbmail/imap4d[10485]: COMMAND: [3 UID fetch 1:*
(FLAGS)]
Mar 20 00:15:11 fork dbmail/imap4d[10485]: COMMAND: [4 UID fetch 12700
(UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date
Message-ID Priority X-Priority References Newsgroups In-Reply-To List-Id
Delivered-To X-Spam-Flag)])]
Mar 20 00:15:12 fork dbmail/imap4d[10485]: COMMAND: [5 UID fetch 12700
(UID RFC822.SIZE BODY.PEEK[])]
Mar 20 00:15:13 fork dbmail/imap4d[10485]: COMMAND: [6 uid store 12700
+Flags (\Seen)]
Mar 20 01:21:54 fork dbmail/imap4d[10485]: ChildSighandler(): got signal
[14]
Not much info I admit, but it's all I have. Perhaps there was some
problem with the SIGALARM (14) handler being called an an inopportune
time. I'm going to set up dbmail-imapd so that I can get it to dump
core. Then if this happens again I'll have more to go on.
Here's my system info for completeness: Debian 3.0 GNU/Linux kernel
2.4.18 on a Sun Ultra 1 with MySQL 3.23.49-8.2 InnoDB.
Hope this helps,
Blake
