[Dovecot] Leaky dovecot-auth ?

[Christian Balzer]

On Tue, 19 Jun 2007 14:39:59 +0300 Timo Sirainen <tss at iki.fi> wrote:
> On Tue, 2007-06-19 at 13:40 +0900, Christian Balzer wrote:
> 
> > 1. How and why would the memory footprint of dovecot-auth grow when
> > there is no change in the amount of users in the DB? 
> 
> The only thing that's changing the size of dovecot-auth is how many
> requests it's simultaneously handling. For example if you try to login
> with invalid user/pass 1000 times within a second, dovecot-auth keeps
> those 1000 requests in memory for a couple of seconds until it returns
> with failure. But this happens also with normal requests, just not for
> so long.
> 
There is nowhere near anything of this kind of concurrency and 
memory should be returned after a while, but that is clearly not
happening. The dovecot-auth is now at 200/160MB and thus prone to
blow up over the weekend I guess.

> 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?

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. 

> > 2. What will happen when the single dovecot-auth process reaches 256MB
> > in the end? Internal housekeeping attempts of that process? A whack to
> > the head from the master process like in 0.99 and thus more erroneous 
> > authentication failures, potentially aggravated by the fact that there
> > is just single dovecot-auth process?
> 
> 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.

Regards,

Christian
-- 
Christian Balzer        Network/Systems Engineer                NOC
chibi at gol.com   	Global OnLine Japan/Fusion Network Services
http://www.gol.com/