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