That seems to be an accurate interpretation. Since you indicated there
is always a read lock on the mbx mailbox, apparently process 6509 can't
complete until the write lock held by pid 518 is released.
The only mbx format mailbox is /var/mail/myuser.mbx, everything else is
a traditional format mailbox, including /home/myuser/Mail/Trash. We're
running version 2006j. The release notes for version 2006k discuss a
very similar problem correcting deadlock issues. Since our mail clients
eventually recover I wasn't positive this was the same problem. If it
is, the deadlock must get broken after a timeout period of about 30 mins.
We're going to install the latest release to see if this fixes our problem.
Ken Keating
Mark Crispin wrote, On 04/15/08 21:33:
In mbx format, there is always a read lock on the mbx mailbox.
If I'm interpreting this output correctly, process 518 is stuck and
sitting on the write lock for the file in question (what format is
/home/myuser/Mail/Trash ?) and that causes the bottleneck.
Also, what version are you running? This may be something that I
already fixed.
On Tue, 15 Apr 2008, Ken Keating wrote:
On Mon, 14 Apr 2008, Ken Mandelberg wrote:
Should there be a problem with imapd serving an mbx INBOX, with
other folders in traditional file format? Some of our users with
that setup report hangs trying to move mail from their INBOX to a
folder.
There should be no problem. UW imapd looks at the mailbox contents to
determine its format, and automatically selects the correct driver.
-- Mark --
I'll try to provide some details so hopefully someone can help us
pinpoint the problem. I gathered some data from my Thunderbird
2.0.0.6 session this morning when this problem occurred. I attempted
to delete a message so it would be moved from my mbx-format inbox to a
traditional-format trash folder. To aid our investigation we wrote a
simple script called imapwho:
[EMAIL PROTECTED] ~]# cat imapwho
#!
if [ $# = 1 ]
then
who="-u $1"
fi
for i in `pgrep $who imap`
do
echo ==============
ps -fp $i |grep -v UID
pfiles $i |egrep "peer|/var/mail|home|lock" |uniq
done
When this problem first appeared, this script showed:
[EMAIL PROTECTED] ~]# imapwho myuser
==============
myuser 585 307 0 08:32:05 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62815
/home/myuser/Mail/Sun_cases/65881036
==============
myuser 564 307 0 08:31:57 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62814
/home/myuser/Mail/Sun_cases/65623982
==============
myuser 545 307 0 08:31:49 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62813
/home/myuser/Mail/Photoshop
==============
myuser 518 307 0 08:31:33 ? 0:01 imapsd
peername: AF_INET 170.140.150.120 port: 62812
/home/myuser/Mail/Trash
==============
myuser 6509 482 0 09:02:25 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62809
advisory read lock set by process 482
/var/mail/myuser.mbx
/home/myuser/Mail/Trash
advisory write lock set by process 518
==============
myuser 482 307 0 08:31:26 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62809
/var/mail/myuser.mbx
About a minute later we see:
[EMAIL PROTECTED] ~]# imapwho myuser
==============
myuser 585 307 0 08:32:05 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62815
/home/myuser/Mail/Sun_cases/65881036
==============
myuser 6686 307 0 09:03:29 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62866
advisory read lock set by process 482
/var/mail/myuser.mbx
==============
myuser 564 307 0 08:31:57 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62814
/home/myuser/Mail/Sun_cases/65623982
==============
myuser 545 307 0 08:31:49 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62813
/home/myuser/Mail/Photoshop
==============
myuser 518 307 0 08:31:33 ? 0:01 imapsd
peername: AF_INET 170.140.150.120 port: 62812
/home/myuser/Mail/Trash
==============
myuser 6710 6686 0 09:03:32 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62866
advisory read lock set by process 6686
/var/mail/myuser.mbx
/home/myuser/Mail/Trash
advisory write lock set by process 518
==============
myuser 6509 482 0 09:02:25 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62809
advisory read lock set by process 6686
/var/mail/myuser.mbx
/home/myuser/Mail/Trash
advisory write lock set by process 518
==============
myuser 482 307 0 08:31:26 ? 0:00 imapsd
peername: AF_INET 170.140.150.120 port: 62809
advisory read lock set by process 6686
/var/mail/myuser.mbx
Note the concurrent advisory read and write locks. Once this occurs
we continually get an authentication and an attempt to move the
message every 1+ minutes. This results in two more imapsd processes
being started. After about 30 mins everything clears up and the
message is successfully moved. All other mail actions are suspended
during this time. Just before recovery there are 26 imapsd processes
with read and write locks as well as 26 imapsd processes with read
locks on the inbox. A ps at this time shows (note: the problem began
around the time the 9:02:25 imapsd process was started):
[EMAIL PROTECTED]> ps -ef|grep myuser|grep imap|grep -v grep|sort -k5
myuser 482 307 0 08:31:26 ? 0:00 imapsd
myuser 518 307 0 08:31:33 ? 0:01 imapsd
myuser 545 307 0 08:31:49 ? 0:00 imapsd
myuser 564 307 0 08:31:57 ? 0:00 imapsd
myuser 585 307 0 08:32:05 ? 0:00 imapsd
myuser 6509 482 0 09:02:25 ? 0:00 imapsd
myuser 6686 307 0 09:03:29 ? 0:00 imapsd
myuser 6710 6686 0 09:03:32 ? 0:00 imapsd
myuser 6861 307 0 09:04:37 ? 0:00 imapsd
myuser 6862 6861 0 09:04:38 ? 0:00 imapsd
myuser 6999 307 0 09:05:42 ? 0:00 imapsd
myuser 7009 6999 0 09:05:45 ? 0:00 imapsd
myuser 7182 307 0 09:06:50 ? 0:00 imapsd
myuser 7199 7182 0 09:06:52 ? 0:00 imapsd
myuser 7327 307 0 09:07:56 ? 0:00 imapsd
myuser 7330 7327 0 09:07:58 ? 0:00 imapsd
myuser 7859 307 0 09:09:03 ? 0:00 imapsd
myuser 7922 7859 0 09:09:15 ? 0:00 imapsd
myuser 8423 307 0 09:10:20 ? 0:00 imapsd
myuser 8427 8423 0 09:10:21 ? 0:00 imapsd
myuser 8534 307 0 09:11:26 ? 0:00 imapsd
myuser 8535 8534 0 09:11:29 ? 0:00 imapsd
myuser 8675 307 0 09:12:34 ? 0:00 imapsd
myuser 8676 8675 0 09:12:36 ? 0:00 imapsd
myuser 8901 307 0 09:13:40 ? 0:00 imapsd
myuser 8902 8901 0 09:13:42 ? 0:00 imapsd
myuser 9055 307 0 09:14:48 ? 0:00 imapsd
myuser 9073 9055 0 09:14:49 ? 0:00 imapsd
myuser 9233 307 0 09:15:52 ? 0:00 imapsd
myuser 9237 9233 0 09:15:54 ? 0:00 imapsd
myuser 9511 307 0 09:16:59 ? 0:00 imapsd
myuser 9529 9511 0 09:17:13 ? 0:00 imapsd
myuser 9827 307 0 09:18:16 ? 0:00 imapsd
myuser 9828 9827 0 09:18:19 ? 0:00 imapsd
myuser 10126 307 0 09:19:24 ? 0:00 imapsd
myuser 10135 10126 0 09:19:27 ? 0:00 imapsd
myuser 10926 307 0 09:20:31 ? 0:00 imapsd
myuser 10927 10926 0 09:20:35 ? 0:00 imapsd
myuser 11624 307 0 09:21:38 ? 0:00 imapsd
myuser 11625 11624 0 09:21:40 ? 0:00 imapsd
myuser 12100 307 0 09:22:44 ? 0:00 imapsd
myuser 12101 12100 0 09:22:45 ? 0:00 imapsd
myuser 12534 307 0 09:23:49 ? 0:00 imapsd
myuser 12539 12534 0 09:23:52 ? 0:00 imapsd
myuser 12878 307 0 09:24:56 ? 0:00 imapsd
myuser 12881 12878 0 09:24:58 ? 0:00 imapsd
myuser 13309 307 0 09:26:03 ? 0:00 imapsd
myuser 13348 13309 0 09:26:15 ? 0:00 imapsd
myuser 13799 307 0 09:27:20 ? 0:00 imapsd
myuser 13828 13799 0 09:27:22 ? 0:00 imapsd
myuser 14251 307 0 09:28:25 ? 0:00 imapsd
myuser 14252 14251 0 09:28:28 ? 0:00 imapsd
myuser 14623 307 0 09:29:31 ? 0:00 imapsd
myuser 14627 14623 0 09:29:37 ? 0:00 imapsd
myuser 15077 307 0 09:30:41 ? 0:00 imapsd
myuser 15078 15077 0 09:30:45 ? 0:00 imapsd
[EMAIL PROTECTED]> ps -ef|grep myuser|grep imap|grep -v grep|wc
56 448 3248
Ken Keating
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
-- 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
