On Tue, 2 Aug 2005, Marc Perkel wrote:

Todd,

I'm using Fedora Core 4. The problem seems to have gone away. Not sure what I did to fix it.

I changed this:

mechanisms = plain

I have this set as well. I see this problem fairly often and it usually resolves itself after a few minutes.

I also put the user dovecot in the mail group. That might have fixed it.

I haven't tried that one...

One thing I'd like to suggest is that this error would be better if it had more information about what resource wasn't available.

The error is EAGAIN caused from the socket() system call.

Looking at socket(7), I see this:

    It is possible to do non-blocking IO on sockets by setting
    the  O_NONBLOCK  flag  on  a  socket file descriptor using
    fcntl(2).  Then all operations that would block will (usu�
    ally)  return  with  EAGAIN  (operation  should be retried
    later); connect(2) will  return  EINPROGRESS  error.   The
    user  can  then  wait  for  various  events via poll(2) or
    select(2).

Near as I can tell, this is what it's supposed to mean, but the error seems to be generated before the O_NONBLOCK gets set.

Todd Burroughs wrote:

...

On Mon, 1 Aug 2005, Marc Perkel wrote:

...

What would cause this?

dovecot: Jul 31 19:31:17 Error: imap-login: Can't connect to auth server at default: Resource temporarily unavailable

What OS are you using? I see the same problem, but haven't been able to figure out why yet. I'm running SuSE Linux 9.2 with a 2.6 kernel.

It should mean something like you've run out of file descriptors or sockets, but that doesn't seem to be the case here.

Todd

-- Marc Perkel - marc@perkel.com

Spam Filter: http://www.junkemailfilter.com My Blog: http://marc.perkel.com

On Sun, 7 Aug 2005, Timo Sirainen wrote:

On Tue, 2005-08-02 at 17:19 -0400, Todd Burroughs wrote:

...

...

One thing I'd like to suggest is that this error would be better if it had more information about what resource wasn't available.

The error is EAGAIN caused from the socket() system call.

Are you sure? My Linux's man page or UNIX98 man page doesn't say that socket() could ever return EAGAIN. If it's out of file descriptors or something else, it should return EMFILE or ENFILE.

connect() however can return EAGAIN:

  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.

It can't be about local ports since UNIX sockets don't use ports.

I think you're right. In the socket() manpage, it says that other errors could be generated by the underlying protocol modules. I'm not sure why, but was thinking that it came from this. It looks like UNIX sockets will not generate this error either.

I think I found this in the kernel in unix_stream_connect(). It looks like the backlog for waiting sockets gets too high and causes this error. It can be set with /proc/sys/net/core/somaxconn, which defaults to 128. I've set this to 1024 and will have to wait to see if it helps.

Todd

On Mon, 15 Aug 2005, Timo Sirainen wrote:

On Mon, 2005-08-08 at 20:12 -0400, Todd Burroughs wrote:

...

...

...

...

One thing I'd like to suggest is that this error would be better if it had more information about what resource wasn't available.

The error is EAGAIN caused from the socket() system call. .. I think I found this in the kernel in unix_stream_connect(). It looks like the backlog for waiting sockets gets too high and causes this error. It can be set with /proc/sys/net/core/somaxconn, which defaults to 128. I've set this to 1024 and will have to wait to see if it helps.

I've also changed the code in CVS now to retry a few times if it gets EAGAIN error.

Changing somaxconn didn't work, I'm installing the latest CVS now.

Todd