[Dovecot] High level of pop3 popping causing server to become unresponsive

[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


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 at 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.
>>
>>
>>
>