[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