Bug#358742: cyrus21-imapd process hangs on sent mailbox

[Henrique de Moraes Holschuh]

On Fri, 24 Mar 2006, Matt Boes wrote:
> Apologies if this is supposed to go somewhere else-Debian's bug tracking 
> is not so clear on what to do from here.

Just make sure you keep the bug#@bugs.debian.org address on the CC list (use
reply-to-all) and it will do the right thing :)

> The user reports it to me-it happens so randomly it's impossible to 
> predict.  There is no way to see a hang of 100 seconds, since I normally 
> find out an hour or so after it happens.

Hmm. Well, if the user's computer is sync'd to NTP and so is your server,
you could ask him to note down the time when he noticed the hang, that'll
give you the datapoint (it will be just a log timestamp comparison away)...

> This user has the largest mailbox on the system, about 3.9GB.  It's not 

Hmm, that might be important.  No quotas, I hope.  Cyrus < 2.3 cannot handle
quotas of that size, and it does many weird things if you try.

> the largest by a lot though, there are a few others with over 3GB.  I 
> and about five others in the company use the same Thunderbird version.

Thunderbird can be configured to use multiple IMAP connections, tell it to
use one and see if that fixes the apparent issue (the bug will still be
there, but you will not hit it anymore).  Certainly don't let it open more
than two connections, Cyrus 2.1 in Debian is patched to be friendly to such
usage, but it causes lock contention for no good reason.

> happened again.  Another piece of interest-he said that every time it 
> happened he was sending an attachment.

We'd need to know more about how Thunderbird sends attachments.  But I'd
guess this means that the IMAP APPEND window is large....

> >The only thing I can think about right now that might fix the problem is
> >this:  edit lib/lock_fcntl.c, function setsigalrm().  Add "alarm(0);" 
> >before
> >"lock_gotsigalrm = 0;".  Rebuild cyrus.  Please report back if that fixes
> >the issue.
> > 
> >
> Unfortunately, I am unable to put a rebuilt version on this server, as 
> it is a production system and the company has rules about that.  Is 
> there anything I could do that doesn't require a rebuild?  I will 
> propose this, but I foresee a "no".

There is a way to have this done with a rebuild but which won't affect any
other user.  Rebuild the package with the patch, but don't install it on the
server.  Copy the new imapd executable in the modified package to the server
renaming it to imapd2 for example.  Place it on /usr/lib/cyrus/bin.  Now
edit cyrus.conf and add a new service pointing to imapd2 and active in an
convenient non-default port.  Tell your user to change his configuration to
use IMAP on that port.  Remember that if you call this service imapt, for
example, you may need an imapt line on /etc/hosts.allow, and if using PAM,
on /etc/pam.d as well.

That way, just that single user will be using the modifed daemon.  The
change I proposed is absolutely innocuous to all data structures on disk, so
it won't cause trouble to the production system.


There is another way to help this.  The issue is definately a locking mishap
in lib/lock_fcntl.c.  If you dig C, you can help me doing a fine combing
over that thing and trying to see if the code fails to handle EINTR
anywhere, or if there is a failure mode where a lock is failing to be
released (on a error path, most probably).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh