On Wed, May 24, 2006 at 06:21:56PM -0400, Sam Varshavchik wrote:
> >We made a little testpatch for the opensock() function in
> >authdaemonlib.c.
> >
> >We patched the source because under high load, the imap and pop
> >daemons (more than one ;-) can simutaniously block the socket to the
> >authdaemond, so that another imap/pop daemon can not connect to the
> >socket. This will lead to really ugly tempfails and the user has to
> >retype the password.
> >
> >Whats new:
> >
> >If we can not connect to the UNIX socket, wait (random between 0.9s -
> >1.1s) and try again. Do this max 10 times and if the socket is still
> >not available, exit with "authentication failed".
>
> Wrong.
>
> The correct solution is to increase the number of authdaemond processes, in
> the authdaemonrc configuration file.
But his patch seems only to make a difference in the case of EAGAIN.
According to the connect(2) manpage:
EAGAIN No more free local ports or insufficient entries in the routing
cache. For PF_INET see the net.ipv4.ip_local_port_range sysctl
in ip(7) on how to increase the number of local ports.
But the unix(7) manpage doesn't list EAGAIN.
In any case, if all the authdaemond processes are busy (i.e. maxdaemons is
too small), would you really get EAGAIN in that case? I would have thought
something like ECONNREFUSED or ETIMEDOUT, but I've not tested it.
Regards,
Brian.
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Courier-imap mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap