In some email I received from Blake <[EMAIL PROTECTED]> on Wed, 26 Mar 2003 12:06:19 -0800, wrote:
> 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: Where can i find the patch? Thanks > 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.) Does it acts differently without stunnel? > 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. core with kill -ABTR ? try attaching gdb? Can you shows us the dbmail-imapd part from dbmail.conf? > 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. did you tried it on a different arch? like x86/alpha? if yes, did you have the same problems too? different? cheers, -lou
