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.
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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:
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
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
