During the last time that the load went up, it became unable to login / su to root for the entire period that dovecot was running, we had to kill dovecot and go back to Popa3d until the mailq was cleared up. We are running CentOS 5.6 server. Based on TOP running at the time the CPU usage was running under 10%. Once Dovecot was killed, we were then able to log in /su again.
We were under the impression that checking to shadow directly should be the fastest and least amount of overhead, is any of the other ways to connect have less load on authentication to PAM?
Thanks,
Kevin
On Thu, May 17, 2012 at 4:57 PM, Timo Sirainen tss@iki.fi wrote:
On 17.5.2012, at 18.22, Root Kev wrote:
We have put Dovecot 2.1.4 on several of our production servers (CentOS, on Dell R710, with 20GB memory, dual CPU Quad-core). We have a single instance of Dovecot running and currently have several instances of Popa3d. When there are significant amount of popping from 2 mailboxes that dovecot that is popping from (500+ msgs in the mailboxes), the popping of the messages causes the boxes to become unresponsive. We use another application that connects to the Dovecot, downloads 2-10 messages, then processes them, then sends the delete command to Dovecot.
Unresponsive for a long time?.. What CentOS version?
When this issue occurs we are unable to become Root, or login again if we close our ssh connection. This only occures when Dovecot is doing the popping. If we only run the older Popa3d, this doesn't occur. We believe it is caused by the way dovecot is authenticating.
Sounds like PAM is hanging. Is the (CPU) load in general high at this time?
We are using auth_mechanisms = plain
passdb drive = shadow
usedb driver = passwd args = blocking=yes
Using shadow/passwd directly shouldn't affect PAM at all. So this is a rather strange problem..