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

[Matt Boes]

>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)...
>  
>
Ok, I'll have him write down the next time it happens.

>  
>
>>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.
>  
>
Nope, no quotas.

>  
>
>>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.
>  
>
I'll let him know about the single connection fix, but after I try to 
fire the bug again with your recommendation below.

>  
>
>>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).
>  
>

I'll try this hopefully Monday.  Thanks for the suggestions!
The only issue is trying to fire the bug.  I can work with you more on 
it over the next week.