On Thu, 2007-06-21 at 16:49 +0900, Christian Balzer wrote: > > You could try http://dovecot.org/patches/debug/mempool-accounting.diff > > and send USR1 signal to dovecot-auth after a while. It logs how much > > memory is used by all existing memory pools. Each auth request has its > > own pool, so if it's really leaking them it's probably logging a lot of > > lines. If not, then the leak is elsewhere. > > > I grabbed the Debian package source on a test machine (not gonna chance > anything on the production servers), applied the patch, did add > --enable-debug to the debian/rules file (and got the #define DEBUG > in config.h), created the binary packages, installed, configured, > started them, tested a few logins and... nothing gets logged > in mail.* if I send a USR1 to dovecot-auth. Anything I'm missing?
Bug, fixed: http://hg.dovecot.org/dovecot-1.0/rev/a098e94cd318 > But no matter, it is clearly leaking just as bad as 0.99 and I venture > that his is the largest installation with LDAP as authentication backend. > I wonder if this leak would be avoided by having LDAP lookups performed > by worker processes as with SQL. Then you'd only have multiple leaking worker processes. > > The same as 0.99. You could also kill -HUP dovecot when dovecot-auth is > > nearing the limit. That makes it a bit nicer, although not perfectly > > safe either (should fix this some day..). > > > If that leak can't be found I would very much appreciate a solution that > at least avoids failed and/or delayed logins. That would require that login processes don't fail logins if connection to dovecot-auth drops, but instead wait until they can connect back to it and try again. And maybe another alternative would be to just disconnect the client instead of giving login failure.
signature.asc
Description: This is a digitally signed message part
