Ok, I think I have come a little further.

When dovecot stops accepting connections, I checked netstat and found this:

[root@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@hldns.com 602-793–0014

On 7/28/15, 3:21 PM, "dovecot on behalf of Steffan Cline" 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@hldns.com 602-793–0014

On 7/28/15, 11:53 AM, "Managed Pvt nets" mpn@icabs.co.zw wrote:

...

On 28/07/2015 7:07:44 PM, "Steffan Cline" steffan@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.

hi ya

On Tue, Jul 28, 2015 at 11:35:31PM -0400, Chris Ross wrote:

...

On Jul 28, 2015, at 21:52 , Steffan Cline steffan@hldns.com wrote:

Ok, I think I have come a little further.

When dovecot stops accepting connections, I checked netstat and found this:

[root@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

are you sure thee are legitimate incoming imaps connections from those 107.212.x.x IP# address ??

they could just be probing your server for vulnerability before attacking what ports are used or not ... etc etc..

the fact that doveocot replies to telnet localhost 993 is a good thing, that imaps "should work" ...

you can also go one step further and check the certs belong to you: outsidePC# openssl s_client -connect imaps.your-domain.com:993

if it is your own real connnections attempts from your customers/employee, you might have a problem, that requires more info ...

if you do NOT receognized those IP#, don't worry, except that you do need to add imaps and pop3s into /etc/hosts.allow to allow legit connectons and all other script kiddies should be dropped. similarly, your firewall should be configured to tarpit un-authorized new tcp connections to port 993

...

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.

ditto

I hope this feedback is helpful.

pixie dust alvin

• http://NetworkNightmare.net/OpenSSL

-----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@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-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Tue, 28 Jul 2015, Steffan Cline wrote:

please, don't top post.

I checked 993 since I was using SSL for sending/receiving but imagine it’ll look the same if I check any of the other ports.

When I tested via telnet, I checked from my home, not on the server to itself. “telnet host.com imap”

Then take Chris's suggestion into account and re-try from localhost in order to rule out network problems.

I don’t have an answer for you on the state yet since it’s working at the moment.

As far as which processes, I try to connect and no matter what, I don’t get the greeting in this state.

Can you connect to other ports of the machine? Or perhaps ping? If the network simply drops all packets, you would get your described problem easily, incl. the SYN_RECV connections.

On 7/28/15, 10:53 PM, "dovecot on behalf of Steffen Kaiser" wrote:

...

-----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@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-----

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQEVAwUBVbhxKHz1H7kL/d9rAQKsyQf/fHF2Avp2F7eD4h5n0cmdzLMTjolFeW28 tsw81m6o+cs5Vl6cqIzzDIDhC1zRjCOqZWQjv8TNx4S0EKIKscXvurvD2A2WdAOz yeYvQpc5sCABSKMLuUQ5wAR4Hv3pcnpJRN3c9pYRQ48Yxd3ORK8r4BzJ3Ol0RK0H Vn5C05pVYWo+Eh4vLWlWSOTgqaJBwQK9DjfhYZOUdzdx5cMKICn1IHQ9GUBSf6YR TwZMfbYfJYUcq/0s3c6POd9hCEOyQjk7SAhgiXL/LSJtXN39U+Ea2pYD+4/VIPHi FR6Pcb71kqNJmTdEvdPADeKT89l1o5yYju5MU+QKzh23iJ0oiUzPvw== =Lgkl -----END PGP SIGNATURE-----