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.
signature.asc
Description: This is a digitally signed message part