A BUGNOTE has been added to this bug. ====================================================================== http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000217 ====================================================================== Reported By: robertcl Assigned To: ====================================================================== Project: DBMail Bug ID: 217 Category: IMAP daemon Reproducibility: random Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 09-Jun-05 10:00 CEST Last Modified: 14-Jun-05 09:17 CEST ====================================================================== Summary: Uploading via IMAP can force IMAP daemon to loop Description: In an e-mail client (I have been using Apple Mail), select a number of mail messages (20+) and drag them into an IMAP inbox or folder. The upload goes slow and quite often, although not always, the IMAP daemon starts looping, consuming all available CPU on the system, causing a denial of service situation for most other users.
Uploading a single messages or a small number of messages typically goes well. ====================================================================== ---------------------------------------------------------------------- sr - 09-Jun-05 16:59 CEST ---------------------------------------------------------------------- We recently migrated a customer's mail service from cyrus to dbmail 2.0.4 We added the new server and let the users move their mail from the old mailbox to the new one (the client is OE 6). Some of them have 5-6 thousand messages and they moved hundreds of them at a time with no problem whatsoever. Of course I'm not denying you had a problem, but it might be something related to your system/mail client edited on: 09-Jun-05 16:59 ---------------------------------------------------------------------- paul - 09-Jun-05 18:51 CEST ---------------------------------------------------------------------- I would appreciate a trace_level=5 log of such a transaction. It could well be AppleMail is using some combination of commands that triggers this. ---------------------------------------------------------------------- robertcl - 11-Jun-05 15:41 CEST ---------------------------------------------------------------------- It is likely so that Apple Mail (the one in MacOS X) uses unusual combinations of IMAP commands that triggers the behavior. At one time I've also used Microsoft OE under Windows to perform similar uploads without any effects on the load of the system. ---------------------------------------------------------------------- robertcl - 13-Jun-05 15:53 CEST ---------------------------------------------------------------------- I just happened to watch it happen, unfortunately with trace_level=1. I dumped a small part of the log to a text file, which is uploaded as "imapd.log". ---------------------------------------------------------------------- aaron - 13-Jun-05 16:08 CEST ---------------------------------------------------------------------- At trace_level=1, the only thing I see is that the message: "dbmsgbuf.c,db_dump_range: adding '^M' to buf" ...should be at a higher trace level, because it is a minor debugging message. Anything other than trace_level=5 will not be useful. ---------------------------------------------------------------------- robertcl - 13-Jun-05 16:23 CEST ---------------------------------------------------------------------- Please disregard my last comment. I just checked and noticed that IMAPD is indeed set to log_level=5 in /etc/dbmail.conf (generating a truly astonishing amount of information on a busy production system). Thus, "dbmsgbuf.c,db_dump_range: adding '^M' to buf" is about as much information as you can get. ---------------------------------------------------------------------- robertcl - 13-Jun-05 16:33 CEST ---------------------------------------------------------------------- The file imapd2.log shows the start of a typical command, which then continues as shown in imapd.log. With two imap daemons executing similar such commands, 45.7% of the CPU is spend in system space and 6.1% is spent in user space. However this doesn't represent the more severe condition I originally reported. I'm still working on trying to get good logs of that. ---------------------------------------------------------------------- aaron - 13-Jun-05 20:39 CEST ---------------------------------------------------------------------- Yeah -- I noticed that the message is in fact at TRACE_DEBUG -- that's level 5. I wonder if the "adding '^M' to buf" message being repeated at such a high rate is the actual looping problem? Unfortunately we can't simulate anything until we have the imap commands that were issued. Are you handy with a packet sniffer? It might be easier to just grab the entire session over-the-wire. I actually haven't done this for more than simply trivial network testing, so hopefully either you or somebody else can post better directions. Thanks for persevering through this bug report! We'll find the bug eventually :-) ---------------------------------------------------------------------- paul - 14-Jun-05 09:17 CEST ---------------------------------------------------------------------- I see a faulty lower-bounds check in db_dump_range. Not sure that's the problem here though. I've committed a fix. Robert, could you please test a little? Bug History Date Modified Username Field Change ====================================================================== 09-Jun-05 10:00robertcl New Bug 09-Jun-05 16:58sr Bugnote Added: 0000732 09-Jun-05 16:59sr Bugnote Edited: 0000732 09-Jun-05 18:51paul Bugnote Added: 0000733 11-Jun-05 15:41robertcl Bugnote Added: 0000736 13-Jun-05 15:52robertcl File Added: imapd.log 13-Jun-05 15:53robertcl Bugnote Added: 0000738 13-Jun-05 16:08aaron Bugnote Added: 0000739 13-Jun-05 16:23robertcl Bugnote Added: 0000740 13-Jun-05 16:30robertcl File Added: imapd2.log 13-Jun-05 16:33robertcl Bugnote Added: 0000741 13-Jun-05 20:39aaron Bugnote Added: 0000742 14-Jun-05 09:17paul Bugnote Added: 0000743 ======================================================================
