[Dovecot] auth process(es)

[Timo Sirainen]

On Wed, 2007-06-13 at 11:04 +0200, Thomas Hummel wrote:
> Hello Timo,
> 
> I've got some questions about dovecot-auth processes which I cannot
> answer just by reading the doc :
> 
> [ Note : my problem is that I often see 
> 
>    dovecot: pop3-login: Can't connect to auth server at default: Connection refused
> 
> and I'm looking for a way to tweak dovecot.conf parameters to allow more login <-> auth connections
> 
> ]
>  
>   - I'm not sure I get the auth worker process concept right : is
>     there a master dovecot-auth which listens to new incoming connections
>     from login processes and fork/exec the real job of authenticating
>     against the pass/userdbs to a child, called an auth worker ?

dovecot-auth keeps a number of connections to auth workers. Whenever all
of them are working it creates a new connection to auth-worker socket.
Dovecot master process then notices this connection and creates a new
auth worker process.

Auth workers are used only with MySQL auth, or if you're using
blocking=yes with passwd or PAM. With others everything is done in the
main dovecot-auth process.

>   - is it safe to increment the number of auth processes (the 'count'
>     parameter in the auth block (auth_default { ...} for instance) ?

Should be.

>   - my understanding is that login processes communicate with auth
>     processes through a unix type socket (named 'default') :
> 
>     can I create a second auth block in dovecot.conf (for instance
>     'aut extra {...}') in addition to the existing 'auth default {...}'
>     one ? would it create an second unix socket and thus allowing a heavier 
>     login processes load ?
> 
>     what would be the difference between that and, say, changing the
>     'count' parameter to '2' in the 'auth default' section ?

Increasing count allows heavier load, because there are then more
processes listening for incoming connections in the same socket.

Creating a second auth block is pretty pointless. It creates a new auth
socket and then login processes connect to both of them and somewhat
randomly pick either one of them to authenticate against. If the first
didn't work it tries the other. Originally I thought that this could be
useful for running multiple dovecot-auths with different mechanisms and
different permissions. But no-one does this.

You could also use login_process_per_connection=no so it would use
persistent imap-login processes without having to reconnect to
dovecot-auth all the time. http://wiki.dovecot.org/LoginProcess
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070613/d2d55a3d/attachment.bin