[Dovecot] logging issues w/ login_max_processes_count on 1.x

Douglas Mortensen doug at impalanetworks.com
Fri Mar 4 22:29:19 EET 2011


Hmm. Is there any reason why it wouldn't show up for me, when I'm 99% positive we were hitting the max & still having new connections come in?

Here's what I get when I grep my logs for those statements:

servername:~# cd /var/log
servername:/var/log# ls mail.*
mail.err    mail.err.2.gz  mail.err.4.gz  mail.info.1     mail.info.3.gz  mail.log    mail.log.2.gz  mail.log.4.gz   mail.warn    mail.warn.2.gz  mail.warn.4.gz
mail.err.1  mail.err.3.gz  mail.info      mail.info.2.gz  mail.info.4.gz  mail.log.1  mail.log.3.gz  mail.stats.log  mail.warn.1  mail.warn.3.gz
servername:/var/log# zegrep "Connection queue full|login_max_processes_count" mail.*
servername:/var/log#


In other words, nothing. I'm assuming that the log output you specified is case sensitive, as that's what I grep'ed for.

Thanks,
-
Doug Mortensen
Network Consultant
Impala Networks
P: 505.327.7300


>As long as all of the connection slots aren't used for SSL connections, it should log:

>Disconnected: Connection queue full

>as some (not yet logged in) client's disconnection reason. It kills the oldest client away. This is actually what v2.0 also does in that situation, it just logs that extra warning. If all of the login processes are busy serving SSL sessions, v1.x logs:

>All login processes are in use. You may need to increase login_max_processes_count




More information about the dovecot mailing list