dovecot - Sep 2005 - Can't connect to auth server at default: Connection refused

We've being running with Dovecot 1.0-stable since Tuesday, and on the 
whole it's gone very well (meaning nobody's noticed!). My best estimate 
is we're using half the disk accesses and 2/3 the CPU of UW-IMAP/Qpopper.

We've quite a mixture of error messages in the logs, the most worrying 
of which is that several times we've had a few seconds of "xxx-login: 
Can't connect to auth server at default: Connection refused" (where xxx
is pop or imap). It seems to sort itself out shortly afterwards. We're 
using userdb=passwd, passdb=passwd (authenticating via NIS). From 
Tuesday we'll be using passdb=pam (pam_ldap to Active Directory).

My first guess is that some dovecot-auth process stops responding and 
gets killed off. Is this right?

Other errors we're seeing include
1) pread_full() failed with mbox file /export/mail/c/37/sau04djp/INBOX: 
No such file or directory (when there is!)
2) mbox sync: UID inserted in the middle of mailbox (especially with 
.prayer folders - configuration folders for our Webmail)
3) file mbox-lock.c: line 505 (mbox_lock): assertion failed: (lock_type 
== F_RDLCK || ibox->mbox_lock_type != F_RDLCK)

presumably some of these are fixed in alpha2.

Best Wishes,
Chris

-- 
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
Whiteknights, Reading, RG6 2AF, UK              Fax: +44 (0)118 975 3094

On Sun, 2005-09-18 at 16:02 +0100, Chris Wakelin wrote:
> We've being running with Dovecot 1.0-stable since Tuesday, and on the 
> whole it's gone very well (meaning nobody's noticed!). My best
estimate
> is we're using half the disk accesses and 2/3 the CPU of
UW-IMAP/Qpopper.
> 
> We've quite a mixture of error messages in the logs, the most worrying 
> of which is that several times we've had a few seconds of
"xxx-login:
> Can't connect to auth server at default: Connection refused"
(where xxx
> is pop or imap). It seems to sort itself out shortly afterwards. 
Probably means that dovecot-auth is getting a lot of connections at the
time and kernel just returns connection refused. With 1.0alphas I've
already done one change for this, committing to 1.0-stable CVS too:

diff -u -r1.1.1.1 auth-server-connection.c
--- src/lib-auth/auth-server-connection.c	31 Jan 2005 16:37:55 -0000	1.1.1.1
+++ src/lib-auth/auth-server-connection.c	23 Sep 2005 12:49:57 -0000
@@ -192,9 +192,17 @@
 	struct auth_server_connection *conn;
 	const char *handshake;
 	pool_t pool;
-	int fd;
+	int fd, try;
 
-	fd = net_connect_unix(path);
+	/* max. 1 second wait here. */
+	for (try = 0; try < 10; try++) {
+		fd = net_connect_unix(path);
+		if (fd != -1 || errno != EAGAIN)
+			break;
+
+		/* busy. wait for a while. */
+		usleep(((rand() % 10) + 1) * 10000);
+	}
 	if (fd == -1) {
 		i_error("Can't connect to auth server at %s: %m", path);
 		return NULL;

Another thing that helps is to increase LISTEN_BACLOG in
src/lib/network.c (or maybe just in net_listen_unix()). Looks like with
1.0alpha I'm using 16, but even that should probably be increased..
Changed to 64 now.
> Other errors we're seeing include
> 1) pread_full() failed with mbox file /export/mail/c/37/sau04djp/INBOX: 
> No such file or directory (when there is!)
The error message is wrong. Should have been "X-IMAPbase uid-last
unexpectedly points outside mbox file". Some problems related this this
are fixed in 1.0alphas without having been backported to 1.0stable..
> 2) mbox sync: UID inserted in the middle of mailbox (especially with 
> .prayer folders - configuration folders for our Webmail)
These are always a bit strange. Some might be fixed in 1.0alpha, but I
know there are still some problems left..
> 3) file mbox-lock.c: line 505 (mbox_lock): assertion failed: (lock_type 
> == F_RDLCK || ibox->mbox_lock_type != F_RDLCK)
I still see this in 1.0alpha too. One way to cause it is to copy mail
from a mailbox within itself, but there probably are some other ways
too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20050923/1e7e7590/attachment.bin>