[Dovecot] auth process(es)
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 ?
is it safe to increment the number of auth processes (the 'count' parameter in the auth block (auth_default { ...} for instance) ?
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 ?
thanks.
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
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
On Wed, Jun 13, 2007 at 02:43:47PM +0300, Timo Sirainen wrote:
Thanks for your answer.
it creates a new connection to auth-worker socket.
all the workers and the auth process communicate through a single unix socket, doesn't they ?
Auth workers are used only with MySQL auth, or if you're using blocking=yes with passwd or PAM.
Why ? what is basically the idea behind that ?
With others everything is done in the main dovecot-auth process.
Ok, so that's my case. So I can safely set auth_worker_max_count to 0, right ?
Increasing count allows heavier load, because there are then more processes listening for incoming connections in the same socket.
That's what I thought.
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.
But in that case, another dovecot-auth process get created as well, doesn't if ? So why isn't the load balanced ?
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
Yes, I tried that.
Should I try something with the 'auth_cache_size' parameter as well ? What would be a reasonable value if its relevant ?
Thanks.
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
On Wed, Jun 13, 2007 at 02:16:55PM +0200, Thomas Hummel wrote:
On Wed, Jun 13, 2007 at 02:43:47PM +0300, Timo Sirainen wrote:
Thanks for your answer.
One more thing : is sending a sighup to the master sufficient for a change to parameters such as 'count' or 'login_process_per_connection' to be taken into account ?
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
On Wed, 2007-06-13 at 14:21 +0200, Thomas Hummel wrote:
On Wed, Jun 13, 2007 at 02:16:55PM +0200, Thomas Hummel wrote:
On Wed, Jun 13, 2007 at 02:43:47PM +0300, Timo Sirainen wrote:
Thanks for your answer.
One more thing : is sending a sighup to the master sufficient for a change to parameters such as 'count' or 'login_process_per_connection' to be taken into account ?
Yep.
On Wed, 2007-06-13 at 14:16 +0200, Thomas Hummel wrote:
On Wed, Jun 13, 2007 at 02:43:47PM +0300, Timo Sirainen wrote:
Thanks for your answer.
it creates a new connection to auth-worker socket.
all the workers and the auth process communicate through a single unix socket, doesn't they ?
There'a a unix socket listener for each auth master process (so with count=2 there are two sockets).
Auth workers are used only with MySQL auth, or if you're using blocking=yes with passwd or PAM.
Why ? what is basically the idea behind that ?
The worker processes are used for passdbs and userdbs that do blocking lookups, so that it doesn't block the whole dovecot-auth while waiting. Other passdbs and userdbs use non-blocking lookups so doing those lookups in worker processes just adds extra overhead.
With others everything is done in the main dovecot-auth process.
Ok, so that's my case. So I can safely set auth_worker_max_count to 0, right ?
Doesn't matter, because the setting isn't used if you don't have any worker processes anyway.
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.
But in that case, another dovecot-auth process get created as well, doesn't if ? So why isn't the load balanced ?
But login process still connects to both of them, and you'll get twice as many connection refused errors.
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
Yes, I tried that.
And doesn't help? You shouldn't get any connection refused errors with login_process_per_connection=no because there are only a few long running login processes that never reconnect to dovecot-auth. If you really do get such errors, it means that dovecot-auth is crashing or something (and the logs should say if it does).
Should I try something with the 'auth_cache_size' parameter as well ? What would be a reasonable value if its relevant ?
No idea. Maybe a megabyte. You can get cache hit/miss statistics by sending USR2 signal to dovecot-auth. What passdb and userdb are you using?
participants (2)
-
Thomas Hummel
-
Timo Sirainen