Am 23.05.2012 16:01, schrieb Root Kev:
Missed CCing on last reply. See below..
Also, would having Nagios checking the number of messages in a mailbox cause issues with the popping of messages? And/Or would having a user accessing the mailbox from two different applications cause issues? Ie. from Outlook and mobile device? I am under the impression that a lock file is generated which should deal with the issue of contention, deleting mail, etc.
Thanks for any information.
Kevin
i have a different setup as yours ( virtual , sql etc ) with dove 2.0.20 and extrem high pop3 traffic no problem so far
same with low pop3 traffic setup dove 2.1.6 no problem reported
anyway use imap
where are your confs and logs ?
Sorry for the delay in responding, long weekend in Canada...
When trying to SSH into the server, the server prompts for user name then password, then just hangs. Same if there is already a console connection over, when trying to SU to root, it just hangs after entering the password.
Our passwords are in the shadow file, and because this is a server dedicated for this task, there is only the default linux users, and maybe 8 other user accounts in the shadow file.
There shouldn't be high IO as all this box does is postfix, pop3ad and dovecot. This box is seeing less then 3000 emails a day, and only has 5 mailboxes on it.
Thanks for the continued suggestions...
Kevin
On Sat, May 19, 2012 at 3:33 PM, Timo Sirainen tss@iki.fi wrote:
On Fri, 2012-05-18 at 09:21 -0400, Root Kev wrote:
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.
Like Kelsey said, a very high disk IO might explain this, although normally the login should still eventually succeed. Another thing I'm wondering is if some process limit reached. How does the login/su fail, does it just hang or immediately fail with some error?
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?
Your passwords really are in /etc/shadow file, not LDAP/something else? I don't think the problem is with authentication. Reading /etc/shadow is pretty fast (unless maybe if it's a huge file) and it anyway can't block login/su from working.
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria