Permissions to the logs are fine. In /var/log/maillog I do see dovecot logging in there but nothing that indicates why there?s a failure. The one thing I thought of is if there?s too many connections but I am using a firewall that blocks excessive attempts but that?s fine. Netstat shows a bunch of CLOSE_WAIT though. I?ll try the debug level and see what I find. Thanks, Steffan Cline steffan at hldns.com 602-793?0014 On 7/28/15, 11:53 AM, "Managed Pvt nets" <mpn at icabs.co.zw> wrote:> > >On 28/07/2015 7:07:44 PM, "Steffan Cline" <steffan at hldns.com> wrote: > >> >>There?s nothing visible in the logs. >You need to check the permissions for your logs. Increase debug level >> >>Suggestions of what to check for? >The logs. Do command line tests, share what you are getting. > >M. >
Ok, I think I have come a little further. When dovecot stops accepting connections, I checked netstat and found this: [root at hosting1 ~]# netstat -an | grep 993 tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN tcp 0 0 65.39.x.x:993 184.101.x.x:36351 SYN_RECV tcp 0 0 65.39.x.x:993 107.212.x.x:51487 SYN_RECV tcp 0 0 65.39.x.x:993 107.212.x.x:51488 SYN_RECV tcp 0 0 65.39.x.x:993 184.101.x.x:44650 SYN_RECV This told me it wasn?t too many connections causing dovecot to be unresponsive. So then I tried via telnet. Dovecot seems to accept connections but then just sits there and does nothing. I used the appropriate commands to try and initiate a login but nothing happens. Typing any commands at all produce no response from dovecot. I then do a ?service dovecot restart? and then telnet again and get this: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. To me this suggests that dovecot is jammed up somehow. I then check in /var/log/maillog and it shows no dovecot entries to indicate a connection. I look in /etc/dovecot and see a dozen conf file. Without reading all the docs, is there any one in particular I can find the verbose logging? What else can I check? Everything was fine until just a couple days ago. This is a SERIOUS issue as I discovered it can be the root cause of a server going down. In my config I use z-push with apache to do active sync with my iPhone. The iPhone connects via z-push/apache and then to dovecot. The connection is stale so eventually with the phone continuously trying to connect and z-push can?t connect to dovecot, the apache processes eat all the RAM until processes crash from no memory. Any help at this point is appreciated. Thanks, Steffan Cline steffan at hldns.com 602-793?0014 On 7/28/15, 3:21 PM, "dovecot on behalf of Steffan Cline" <dovecot-bounces at dovecot.org on behalf of steffan at hldns.com> wrote:>Permissions to the logs are fine. In /var/log/maillog I do see dovecot logging in there but nothing that indicates why there?s a failure. > >The one thing I thought of is if there?s too many connections but I am using a firewall that blocks excessive attempts but that?s fine. Netstat shows a bunch of CLOSE_WAIT though. > >I?ll try the debug level and see what I find. > >Thanks, >Steffan Cline >steffan at hldns.com >602-793?0014 > > > > > > > >On 7/28/15, 11:53 AM, "Managed Pvt nets" <mpn at icabs.co.zw> wrote: > >> >> >>On 28/07/2015 7:07:44 PM, "Steffan Cline" <steffan at hldns.com> wrote: >> >>> >>>There?s nothing visible in the logs. >>You need to check the permissions for your logs. Increase debug level >>> >>>Suggestions of what to check for? >>The logs. Do command line tests, share what you are getting. >> >>M. >> >
> On Jul 28, 2015, at 21:52 , Steffan Cline <steffan at hldns.com> wrote: > > Ok, I think I have come a little further. > > When dovecot stops accepting connections, I checked netstat and found this: > > [root at hosting1 ~]# netstat -an | grep 993 > tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN > tcp 0 0 65.39.x.x:993 184.101.x.x:36351 SYN_RECV > tcp 0 0 65.39.x.x:993 107.212.x.x:51487 SYN_RECV > tcp 0 0 65.39.x.x:993 107.212.x.x:51488 SYN_RECV > tcp 0 0 65.39.x.x:993 184.101.x.x:44650 SYN_RECV > > This told me it wasn?t too many connections causing dovecot to be unresponsive. So then I tried via telnet. > > Dovecot seems to accept connections but then just sits there and does nothing. I used the appropriate commands to try and initiate a login but nothing happens. Typing any commands at all produce no response from dovecot.Actually, I think the above shows that it?s not a dovecot problem. A socket in a SYN_RECV state means that a connection request has been merely been received from the network. That means your kernel has not finished establishing the TCP connection, so dovecot (or the application level in general) is likely not even involved yet. I would suspect some sort of firewall config on your host, or perhaps some sort of overload at the network stack level. But, the latter only if the server were very heavily loaded. I hope this feedback is helpful. - Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 28 Jul 2015, Steffan Cline wrote:> When dovecot stops accepting connections, I checked netstat and found this: > > [root at hosting1 ~]# netstat -an | grep 993 > tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN > tcp 0 0 65.39.x.x:993 184.101.x.x:36351 SYN_RECV > tcp 0 0 65.39.x.x:993 107.212.x.x:51487 SYN_RECV > tcp 0 0 65.39.x.x:993 107.212.x.x:51488 SYN_RECV > tcp 0 0 65.39.x.x:993 184.101.x.x:44650 SYN_RECV > > This told me it wasn?t too many connections causing dovecot to be unresponsive. So then I tried via telnet. > > Dovecot seems to accept connections but then just sits there and does > nothing. I used the appropriate commands to try and initiate a login but > nothing happens. Typing any commands at all produce no response from > dovecot. > > I then do a ?service dovecot restart? and then telnet again and get this: > > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.from which host do you telnet to Dovecot and to which port? Do you get the greeting (last line of your quote), if you telnet? You show port 993 in above listing, which is the IMAP-over-SSL port, you should not see the greeting with telnet on this port at all. In which state are the various dovecot processes in? Do they wait in non-interruptable sleep? ps -eopid,user,fname,state,wchan,args Do all Dovecot processes hang or just new ones, that try to connect and auth? - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVbhqXHz1H7kL/d9rAQJbKQgAlzwvfDNSlP2oliX1SaCFqeiE+mhcZCz/ XUe2ffnw5AYH0hW7jcur7BHpGZM7ajK1drcGy5OGPYTGEknaMRMnaiBza726Qyjc sDoVZD+YR25gtjNAGrqNYyMxNBLyx3JB3CeG0ljcqmxZ4BC1mOAdwjOSUaJsUqPX EOBC+PXE51GWxnPq7XwcEZ36mXAEmaLnyKWhA9CZuwfB9Q9yxJahc3u2yEnAVh+Y kFF/TJksmYQ+GfKAtTEi+S/e2+3xCq6XgS2daEjwr7SDrhV/0Lvz5PW18MqQtUjU IcF72VzJ1/BruU+eawL2G+JUJ1wdmmFBszPyjJtRTB2sMHk/KDXroQ==7wRT -----END PGP SIGNATURE-----