Bug 7237
Summary: | imap attempts dotfile locking and fails | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | dharris | ||||||
Component: | imap | Assignee: | Cristian Gafton <gafton> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 6.1 | CC: | jik | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2000-02-18 00:41:16 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
dharris
1999-11-22 22:35:37 UTC
Created attachment 11 [details]
the caldera flock insteadl of dotlock patch
Created attachment 12 [details]
my switch-to-mail-group-when-needed patch
My strace on procmail shows that it is clearly using dot locking. (procmail- 3.13.1-2 package from RedHat 6.0.) So, I think that I'm going to use my imap- 4.6-mailgroup.patch patch for now. I just realized that in the system trace the line: nanosleep(0x7fffd5f4, 0x7fffd5f4, 0x2abf11b4, 0x7fffd5f4, 0x7fffd708) = 0 done not justify that the sleep was actually a second. I know that the sleep was a second because: (a) I ran systrace with the -T option which shows the time spent in the system call, but I edited this information out to try to make the strace fit in the width of the bug report. (lots of word wrapping stinks). (b) when I looked at the source code, I found a "sleep(1)" right where the sleep was coming from. I think it is correct that imap try to do *both* flock locking and dotfile locking; there's no harm in doing both, and it's an extra layer of protection. What is *not* correct is the "sleep(1)" which causes significant delays when retrieving a small mailbox. I fixed that with this patch: --- imap-4.7/src/osdep/unix/env_unix.c.orig Tue Jan 25 10:55:32 2000 +++ imap-4.7/src/osdep/unix//env_unix.c Tue Jan 25 10:55:49 2000 @@ -858,7 +858,7 @@ break; } /* if failed to make lock file and retry OK */ - if ((ld < 0) && base->lock) { + if ((ld < 0) && base->lock && base->lock[0]) { if (!(i%15)) { /* time to notify? */ sprintf (tmp,"Mailbox %.80s is locked, will override in %d seconds...", file,i); While I agree that for high-load IMAP servers waiting one sec for a dotlock is less than ideal, in practice eliminating the delay will make the dotfile locking useless on such a server. You have a choice of either allowing the imap to create the dotlock entries or disable dotlocking entirely. None of these options are sane enough for the majority of the users, so we'll have to go with whatever suits most of them. Please look at the patch I submitted. I am not proposing that you remove dotlocking. I'm proposing that you fix a *bug in the code* which is causing the 1-second delay when the server already knows that the dotlocking has failed and it is going to proceed without it. There is no reason for the delay at that point. I think that jik.ma.us is right. The behavior i was seeing was a sleep(1) _after_ the dotlocking attempt had failed for lack of permissions to create a file in the /var/spool/mail directory. This sleep(1) was not part of the internal dotlocking mechanics, as the dotlock attempt had already failed. I don't think Red Hat really has it straight what their standard for locking the /var/spool/mail directory is. Here you are saying "lets not screw up the dotlocking" but then in bug id 3914 you (grafton) and pbrown implied that flock/fcntl was the appropriate locking standard for a Red Hat /var/spool/mail. Right now it looks like you have _no_ locking happening between procmail delivery and imapd pickup. Imadp can't dotlock and procmail is dotlocking. No locking is a real problem. Please look further into this. From the 02/17/00 19:41 reply, I don't think you fully understood the bug report. You need to be clear on these issues: (a) what your locking standard is, and (b) are you sure that every /var/spool/mail program uses this same standard? +Right now it looks like you have _no_ locking happening between procmail +delivery and imapd pickup. Imadp can't dotlock and procmail is dotlocking. No +locking is a real problem. That's not correct. Procmail is doing both fcntl and dot-locking, so there should be no problem. Here's output from "strace procmail -d jik": execve("/usr/bin/procmail", ["procmail", "-d", "jik"], [/* 39 vars */]) = 0 ... link("/var/spool/mail/_rCC.yOYr4.jik.kamens.b", "/var/spool/mail/jik.lock") = 0 unlink("/var/spool/mail/_rCC.yOYr4.jik.kamens.b") = 0 ... open("/var/spool/mail/jik", O_WRONLY|O_APPEND|O_CREAT, 0667) = 4 ... fcntl(4, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=565, len=0}) = 0 ... fcntl(4, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=565, len=0}) = 0 close(4) = 0 ... unlink("/var/spool/mail/jik.lock") = 0 ... This is with procmail-3.14-2. The unnecessary sleep(1) is still a bug which should be fixed, but I don't think the locking itself is broken. Oh, okay.. my mistake on that. But I agree with you that the sleep still needs to be removed from imap, because there is really no use for it. If you run IMP which makes three different (sequential) IMAP connections when you login, it is a real drag. |