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 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 <[email protected]> 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. >> >> >> >
