stuck lmtpd processes

[Andrew Morgan]

On Tue, 23 Sep 2003, Rob Siemborski wrote:

> On Tue, 23 Sep 2003, Andrew Morgan wrote:
>
> > I'd prefer not to restart all of cyrus because I have several hundred
> > users connected right now, and this is the day that all the students are
> > returning to campus.  Is there a way I can kill the original lmtpd process
> > that got stuck to free things up?
>
> Killing the lmtpd that is holding the lock should free up the rest of
> them.
>
> Finding out where it is using gdb (if it is blocking on something else, as
> opposed to having fogotten to unlock something) would be useful.

Okay, a little more digging shows that it was stuck trying to get a write
lock on the quota file:

(gdb) bt
#0  0x402ae5fb in fcntl () from /lib/libc.so.6
#1  0x08077504 in lock_reopen (fd=16,
    filename=0xbfffa398 "/var/spool/cyrus/config/quota/k/user.krolickp", sbuf=0xbfffa340,
    failaction=0xbfffa33c) at lock_fcntl.c:87
#2  0x080570b6 in mailbox_lock_quota (quota=0xbfffc6c4) at mailbox.c:1016
#3  0x08053f73 in append_setup (as=0xbfffc418, name=0xbfffb414 "user.krolickp", format=0, userid=0x0,
    auth_state=0x0, aclcheck=0, quotacheck=0) at append.c:209
#4  0x0804de54 in deliver_mailbox (msg=0x812ec00, stage=0x8126ce0, size=8832, flag=0x0, nflags=0,
    authuser=0x0, authstate=0x0, id=0x812ebd0 "<13789734.1064257493060.JavaMail.ml at mx5>",
    user=0x812f058 "krolickp",
    notifyheader=0x812ec50 "From: Netflix Receiving <discship at netflix.com>\nSubject: We've received: Michael Moore's The Awful Truth: Season 2: Disc 1 -- Rate it Now!\nTo: Krolickp at onid.orst.edu\n",
    mailboxname=0xbfffc988 "INBOX", quotaoverride=0, acloverride=1) at lmtpd.c:1116
#5  0x0804e449 in deliver (msgdata=0x811bf78, authuser=0x0, authstate=0x0) at lmtpd.c:1262
#6  0x08050c11 in lmtpmode (func=0x8102040, pin=0x810f8c0, pout=0x810f910, fd=0) at lmtpengine.c:1522
#7  0x0804c707 in service_main (argc=2, argv=0x810ae48, envp=0xbffff990) at lmtpd.c:278
#8  0x0804c448 in main (argc=2, argv=0xbffff984, envp=0xbffff990) at service.c:508

And that write lock was held by an imaps process.  Once I killed the imaps
process, all the lmtpd's got unstuck.  Unfortunately, I realize now that
it would have been nice to get a backtrace on that imaps process to see
why it hadn't released the lock...  :(

If I see this happen again, is there anything else I should do besides get
a backtrace on the process holding the lock?

Thanks for a terrific product.  Aside from a few little gotchas like this,
Cyrus has been a wonderful change from uw-imap.

	Andy