Is it possible that one of these imapd sessions is from the version before
the August 16 tarball? The known mbx deadlock problem was fixed in that
tarball. Please make absolutely sure that you are running only the new
code. If c-client is a shared library on your system (you seem to be
running NETBSD and I believe their ports do that), make sure that shared
library is the August 16 tarball's code.
The stack trace that you have shows that PID 11950 is blocked trying to
acquire exclusive access to the parse/append lock on the mailbox. That
session is a victim, and not the culprit. One of these sessions, probably
the oldest, is the culprit; its stack trace would be interesting.
It is possible that a session stuck doing an APPEND to that mailbox could
sit on the parse/append lock, but it shouldn't do that for 20 hours. At
least not in the August 16 code.
On the other hand, if the glibc mutex doesn't respect setjmp()/longjmp(),
then all bets are off.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
