On Tue, 28 Jun 2005, Kai Wang wrote:
We are running imapd.2004a on redhat AS3. Some users found that they could
not delete messages in their mbox. I found that this is caused by the old
imapd process, which does not work but does not go away. It still exclusively
opens the mbox file which makes other processes unable to access it. I
suspect this is a mbox locking problem.
How do you know that the old imapd process "does not work"? Does it still
have an open TCP/IP connection associated with it?
I think that the most productive use of your time will be to ascertain how
and why it "does not work". Identifying the cause of a problem, and
addressing that cause, usually leads to better results than trying to
repair an unknown problem with an unknown cause.
We are running postfix and procmail on our uw-imap servers. I checked the
locking mechanism used in postfix and procmail. They are in different order.
I don't know how to check what locking uw-imap is using such that I can
identify which one mismatches. I wonder if anybody can help?
With traditional UNIX (mbox) format files, the only trustworthy form of
locking is by the creation of a .lock file. Waits for .lock files expire
after 5 minutes.
imapd will also impose an flock() lock on the mailbox file.
Both the .lock file and the flock() lock on the mailbox file are only when
a program is in the physical act of reading or writing the mailbox file.
The locks are released afterwards.
Finally, Pine and imapd has a session lock (which postfix and procmail do
not know about) between other Pine/imapd sessions. This uses flock() on
specially-named files in the /tmp directory.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
