On Friday 27 October 2006 20:42, Wesley Craig wrote: > On 27 Oct 2006, at 05:08, Libor Pechacek wrote: > >> MAIL FROM:<lpechacek@xxxxxxxxxxx <mailto:lpechacek@xxxxxxx>> > >> SIZE=15311 > >> RCPT TO:<test@xxxxxxxxxxx <mailto:flow@xxxxxxxxxxxxxxxxxxxxx>> > >> DATA > > > > < 250 2.1.0 ok > > < 250 2.1.5 ok > > < 354 go ahead > > > >> . > > > > < 7 lockers > > > > In this case the obvious reason for the error is the "7 lockers" line > > that leaked from BDB. It makes only small harm itself but causes the > > next message to be bounced due to protocol error in case the LMTP > > connection is reused. Workaround to the bounces is simple - > > "lmtp_cache_connection = no" in Postfix's main.cf. > > Here's where this happens in BDB 4.3.29: > > ./lock/lock_deadlock.c-418- *nlockers = 0; > ./lock/lock_deadlock.c-419- return (0); > ./lock/lock_deadlock.c-420- } > ./lock/lock_deadlock.c-421- > ./lock/lock_deadlock.c-422- if (FLD_ISSET(dbenv->verbose, > DB_VERB_DEADLOCK)) > ./lock/lock_deadlock.c:423: __db_msg(dbenv, "%lu > lockers", (u_long)count); > ./lock/lock_deadlock.c-424- > ./lock/lock_deadlock.c-425- count += 20; > ./lock/lock_deadlock.c-426- nentries = (u_int32_t)DB_ALIGN(count, > 32) / 32; > ./lock/lock_deadlock.c-427- > ./lock/lock_deadlock.c-428- /* > > So, first thing is that the message shouldn't be written if this > DB_VERB_DEADLOCK isn't set. Quickly skimming the BDB code, it > doesn't appear that this defaults on. I'm wondering if you have: > > set_verbose db_verb_deadlock > > in your DB_CONFIG file? Once it's on, I don't see a way to turn it > off, other than calling the set_verbose method from within Cyrus. cyrus turns on DB_VERB_DEADLOCK itself. See lib/cyrusdb_berkely.c. It seems that one can turn that off via configure.in before building. But the real problem turned out to be that with BDB 4.3.* they changed the "n lockers" message from __db_err() to __db_msg(). To avoid having __db_msg() messages printed on stdout one needs to install a callback handler with dbenv->set_msgcall() in older versions dbenv->set_errcall() was enough to redirect all messages away from stdout. This problem was BTW fixed with cyrus-imapd-2.2.13. For details see e.g.: https://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/lib/cyrusdb_berkeley.c.diff?r1=1.10&r2=1.11 -- Ralf Haferkamp SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg T: +49-911-74053-0 F: +49-911-74053575 - Ralf.Haferkamp@xxxxxxxx ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
