Richard,
At first glance this doesn't look like a loop to me. I'm sure I don't
understand the current mime-parsing code (nobody does really), but still
I don't see anything obviously suspicious here. If I read this right I
see two messages being retreived.
Next time perhaps you could attach a strace to the runaway process, or
better yet, recompile with the -g switch and attach a gdb session.
Richard Barrington wrote:
It seems to be stuck in a loop, more or less. Here's a log excerpt:
Jul 21 12:04:25 server dbmail/imap4d[28324]: IMAPClientHandler():
Executing command uid...
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_query(): executing query
[SELECT messageblk FROM messageblks WHERE message_idnr = 66339::bigint
ORDER BY messageblk_idnr]
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_start_msg(): starting,
stopbound: '<null>'
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): entering
mime loop
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): found
double newline; header size: 29 lines
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_start_msg(): found
multipart msg
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_start_msg(): found new
boundary: [--112644984159776744], msgidx 1571
Jul 21 12:04:25 server dbmail/imap4d[28324]: update msgbuf updating
29618094604288::bigint 22870700851200::bigint 22870700851200::bigint
0::bigint
Jul 21 12:04:25 server dbmail/imap4d[28324]: update msgbuf: entire fit
Jul 21 12:04:25 server dbmail/imap4d[28324]: update msgbuf succes NOMORE
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_add_mime_children():
starting, splitbound: '--112644984159776744'
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): entering
mime loop
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): found
double newline; header size: 3 lines
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_add_mime_children():
expecting body data...
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_add_mime_children():
found end after boundary [--112644984159776744],
Jul 21 12:04:25 server dbmail/imap4d[28324]:
followed by [-- ],
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_query(): executing query
[SELECT messageblk FROM messageblks WHERE message_idnr = 66379::bigint
ORDER BY messageblk_idnr]
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_start_msg(): starting,
stopbound: '<null>'
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): entering
mime loop
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): found
double newline; header size: 30 lines
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_start_msg(): found
multipart msg
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_start_msg(): found new
boundary: [MuLtIpArT_BoUnDaRy], msgidx 1560
Jul 21 12:04:25 server dbmail/imap4d[28324]: update msgbuf updating
71305047179264::bigint 64604898066432::bigint 64604898066432::bigint
0::bigint
Jul 21 12:04:25 server dbmail/imap4d[28324]: update msgbuf: entire fit
Jul 21 12:04:25 server dbmail/imap4d[28324]: update msgbuf succes NOMORE
Jul 21 12:04:25 server dbmail/imap4d[28324]: db_add_mime_children():
starting, splitbound: 'MuLtIpArT_BoUnDaRy'
Jul 21 12:04:25 server dbmail/imap4d[28324]: mime_readheader(): entering
mime loop
...
Jul 21 16:22:17 server dbmail/imap4d[28324]: db_start_msg(): starting,
stopbound: '<null>'
Jul 21 16:22:17 server dbmail/imap4d[28324]: mime_readheader(): entering
mime loop
Jul 21 16:22:17 server dbmail/imap4d[28324]: mime_readheader(): found
double newline; header size: 28 lines
Jul 21 16:22:17 server dbmail/imap4d[28324]: db_start_msg(): found
singlepart msg
Jul 21 16:22:17 server dbmail/imap4d[28324]: update msgbuf updating
160442798440448::bigint 154008937299968::bigint 154008937299968::bigint
1052748023857152::bigint
Jul 21 16:22:17 server dbmail/imap4d[28324]: update msgbuf: entire fit
Jul 21 16:22:17 server dbmail/imap4d[28324]: update msgbuf succes NOMORE
Jul 21 16:22:17 server dbmail/imap4d[28324]: db_start_msg(): exit
Jul 21 16:22:17 server dbmail/imap4d[28324]: db_query(): executing query
[SELECT messageblk FROM messageblks WHERE message_idnr = 66987::bigint
ORDER BY messageblk_idnr]
Jul 21 16:22:17 server dbmail/imap4d[15529]: StartServer(): child [1388]
hasn't provided exit status yet
Jul 21 16:22:17 server dbmail/imap4d[15529]: StartServer(): child
[13664] is still alive, sending SIGTERM
Jul 21 16:22:17 server dbmail/imap4d[15529]: ParentSigHandler(): got
signal [17]
Jul 21 16:22:17 server dbmail/imap4d[15529]: StartServer(): child
[13664] has exited, zombie cleaned up
I have 140MB of level 5 log file sitting here, so if any more (or more
useful) info is needed, just ask.
Rich.
On Wed, 2004-07-21 at 10:50, Jesse Norell wrote:
These are probably obvious, but turn up logging to level 5 and see
if dbmail-imapd prints anything. I believe there's a way to have
postgres log queries that are being run too, but I don't remember
how. If neither of those provide any hints, you'd probably have
to run a debugger to trace the process. Also, you might record
the imap traffic going over the wire... there's an off chance you
could be getting hit by some as-yet previously unknown bug in the
imap protocol handler or something (but probably look at that as
more of a last resort).
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
