On Thu, Sep 10, 2009 at 11:43 AM, Timo Sirainen <tss@iki.fi> wrote:
On Thu, 2009-09-10 at 14:32 -0400, Jonathan Siegle wrote:
It only helps when I kill dovecot-auth, not dovecot-auth -w.
Interesting..
What if you kill imap-login processes instead?
I don't have imap-login processes associated with inetd spawned dovecot.
Why do you use inetd? I'm currently wondering if I should bother adding inetd support to Dovecot v2.0.
Yes I have truss. So tomorrow when this happens I'll do truss -f -p on the dovecot-auth process?
Yes. Also having auth_debug=yes enabled might show something useful. What does it log last before it stops responding?
I've run across what seems to be the same issue with 1.2.4. I upgraded from a 1.0 release which was not having any issues; however, I'm very afraid to revert because the server gets killed if it has to rebuild caches/indexes. I don't have this issue on lesser loaded 1.2.4 installations, only this server which handles roughly 6000 mailboxes and maintains a higher overall load.
The difference is we aren't doing PAM, we have it disabled. We do SQL authentication only. Exact same symptoms, the server and all active connections remain online; however, new connections coming in via POP3/IMAP hang. The connection is made, but the banner is never shown.
The log, with auth_debug enabled doesn't seem to show anything useful, it only shows a ton of connections being dropped for remaining idle for too long when this begins happening. ie. POP3/IMAP clients are connecting, never getting a banner, and therefore never sending login credentials, then dovecot drops the connection eventually.
System affected is linux 2.6.18 (centos 5.2). Any help diagnosing and fixing this would be greatly appreciated. I'm not sure where to go from here.
- N