No/misleading log messages when "maxchild" is hit

Bug #570862 reported by Nils Toedtmann
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cyrus-imapd-2.2 (Ubuntu)

Bug Description

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


  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

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

Revision history for this message
Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net) wrote :

I filed it upstream too: Hope that is the right thing to do ...?

Revision history for this message
Santiago Lopez (santiajo) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.