[Dovecot] auth process(es)
Timo Sirainen
tss at iki.fi
Sat Jun 16 02:13:02 EEST 2007
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?
-------------- 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/20070616/b12838d6/attachment.bin
More information about the dovecot
mailing list