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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
