No/misleading log messages when "maxchild" is hit

[Nils Toedtmann]

Binary package hint: cyrus-imapd-2.2

When "imapd -s" or "pop3d -s" hit "maxchild", weird things happen:

 * No warning about "maxchild" shows up in syslog's "mail.debug";
 * Clients do neither get a TCP reset nor a TLS error nor a IMAP error;
 * After ages, the client gives up and throws a connection timeout message to the user
 * Eventually, "mail.debug" shows this:

  Apr 26 13:49:23 mail2 cyrus/imaps[7287]: idle for too long, closing connection
  Apr 26 13:49:23 mail2 cyrus/imaps[7287]: accepted connection
  Apr 26 13:49:23 mail2 cyrus/imaps[7287]: imaps TLS negotiation failed: [XX.XX.XX.XX]
  Apr 26 13:49:23 mail2 cyrus/imaps[7287]: Fatal error: tls_start_servertls() failed
  Apr 26 13:49:23 mail2 cyrus/master[19824]: process 7287 exited, status 75
  Apr 26 13:49:23 mail2 cyrus/master[19824]: service imaps pid 7287 in BUSY state: terminated abnormally

or

  Apr 27 11:40:15 mail2 cyrus/pop3s[24466]: pop3s failed: [XX.XX.XX.XX]
  Apr 27 11:40:15 mail2 cyrus/pop3s[24466]: Fatal error: tls_start_servertls() failed
  Apr 27 11:40:15 mail2 cyrus/master[19824]: process 24466 exited, status 75
  Apr 27 11:40:15 mail2 cyrus/master[19824]: service pop3s pid 24466 in BUSY state: terminated abnormally

which is totally misleading because one starts debugging TLS. Instead, i would expect cyrus-imapd to

 * log a warning like "maxchild=100 reached" to make the admin aware that he might want to increase some maxchild limits in /etc/cyrus.conf
 * cut the connection to the client either on TCP level (reset), TLS level or IMAP level

I am not the first one running into this issue, see http://markmail.org/message/hfg6pag63bm23d5o

I am using cyrus-{imapd,pop3d}-2.2 version 2.2.13-13ubuntu3 on "Ubuntu 8.04.4 LTS"

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

I filed it upstream too: https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3207 Hope that is the right thing to do ...?

[Santiago Lopez (santiajo)]

New bugzilla URL: http://bugzilla.cyrusimap.org/show_bug.cgi?id=3207