On Thu, May 25, 2006 at 08:40:52AM +0100, Brian Candler wrote:
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.
OK, I have now. Under FreeBSD 5.4, I set
and installed samplepipe.pl as authProg, but added "sleep(3);" at the top of
Now if I run two authtest commands in two different windows:
then the second waits behind the first. That is, after 3 seconds I get a
result in the first window, then 3 seconds later I get a result in the
second. The requests simply queue up.
I've also tried it with three authtests concurrently, and it's the same.
Now, maybe the semantics of Unix domain sockets are different between
FreeBSD and Linux. However, if they are the same, then it would appear that
having insufficient authdaemons is not a cause of the connect() call failing
with EAGAIN (or conversely, if you are seeing EAGAIN errors, then increasing
the number of authdaemons will not help you)