Subject: [Imap-uw] How to find out what locking mechanism my uw-imapd is using?

From: Kai Wang <[email-masked]>
Date: Tue, 28 Jun 2005 13:35:54 -0600

Hi,

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.

I just read a document about the mbox locking. According th the 
document, if the softwares, which are dealing with mbox, are using 
multiple common locking mechanism, they must be used in the same order 
to avoid deadlocks.

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?

Kai Wang
University of Calgary

_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Tue, 28 Jun 2005 13:31:04 -0700 (Pacific Daylight Time)

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-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Kai Wang <[email-masked]>
Date: Tue, 28 Jun 2005 15:16:05 -0600

I'm not sure if the tcp/ip connection is there. I'm not having such a 
problem at the moment because I kill imap processes older than 1 day 
everyday. The following case happened last Aug 9.

[root@lms2 root]# ps -ef | grep mcpoon
mcpoon    3026   625  0 Aug05 ?        00:00:03 imapd
mcpoon    2412   625  0 09:30 ?        00:00:00 imapd
mcpoon    3655   625  0 09:35 ?        00:00:00 imapd
mcpoon    4395   625  0 09:39 ?        00:00:00 imapd
root      4697 12507  0 09:40 pts/1    00:00:00 grep mcpoon
[root@lms2 root]# lsof ~mcpoon/mbox
COMMAND  PID   USER   FD   TYPE DEVICE     SIZE    NODE NAME
imapd   2412 mcpoon    3r   REG   8,21 56304729 5029899 /fs201/mcpoon/mbox
imapd   3026 mcpoon    4u   REG   8,21 56304729 5029899 /fs201/mcpoon/mbox
[root@lms2 root]# ls -al /tmp | grep mcpoon
-rw-rw-rw-    1 mcpoon   itmail          4 Aug  9 09:39 .815.4cc005
-rw-rw-rw-    1 mcpoon   itmail          4 Aug  5 19:58 .815.4cc00b
-rw-rw-rw-    1 mcpoon   itmail          4 Aug  9 09:36 .815.4cc00c

Kai

Mark Crispin wrote:

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