On Fri, 2009-02-13 at 14:59 -0500, Alan Ferrency wrote:
On Fri, 13 Feb 2009, Timo Sirainen wrote:
On Fri, 2009-02-13 at 14:49 -0500, Alan Ferrency wrote:
Do you think the "idle process holds a lock open forever" problem that you recently patched for pop3 could also affect imap?
It shouldn't. The mailbox is unlocked after each command is finished. But of course if the client sends a command that takes a really long time that could be a problem. I don't think clients usually do that though.
In the only case I've looked into deeply, the imap processes all seem to be sitting in this state, idle:
#0 0x18290f0b in kevent () from /lib/libc.so.6 #1 0x080c97fc in io_loop_handler_run (ioloop=0x80f0160) at ioloop-kqueue.c:128 #2 0x080c8e59 in io_loop_run (ioloop=0x80f0160) at ioloop.c:326 #3 0x08065ed0 in main (argc=1, argv=0xbfbfea1c, envp=0xbfbfea24) at main.c:293
Yep, it shouldn't be locked at this state.
I don't see how that could be holding anything up. It feels a bit odd that clients have 30+ separate imap processes open, all sitting in the io loop.
30+ is a bit much. I think most max at 5 by default.
You could anyway see what locks the process holds and see if any of them point to the mbox file. With Linux I would have done that by grepping /proc/locks, but I've no idea how to do that with BSDs.