Max,
I thought you may find this useful, so I wanted to let you know. I was speaking
with a colleague the other day who was experiencing the same problem with the
"sticky" mailbox syndrome and his solution to the problem was:
1) Wait for the user to call and complain something was wrong.
2) Under /var/imap/proc, find the user's imap sessions and kill them with the
following command:
kill `grep <username> * | cut -f1 -d":"`
3) Then search for the locked LTMP process with the following command:
ps -efl | grep lmtp
4) Look for the process that's been hanging around for a while, and kill the PID.
I haven't actually tried this yet, but it seems like it would work. Does anyone
see any problems with this method?
-John
Max Kalika wrote:
> From: "John C. Amodeo" <[EMAIL PROTECTED]>
>
> > My current config is 2.0.16 / RH 7.1 / 2.4.3-12 kernel
>
> Yes, I'm currently running 2.0.15 on a custom-built 2.4.3 kernel (RH 7.1 as
> well).
>
> > Once in a while, when a user goes to copy a message from their Inbox to
> > a subfolder, it locks their IMAP session, After closing the mail client
> > (Webmail or Netscape Messenger), when they log back in, now they cannot
> > delete any messages in any of their folders, and, in addition, they
> > cannot write to any folders under their account. Furthermore, Postfix
> > starts deferring mail because it cannot write to the users Inbox either.
>
> I configed cyrus to prefork 2 lmtp processes and that is what I see during
> normal operation. But sometimes I periodically notice a bunch of lmtp
> processes hanging about. Restarting cyrus became problematic because my users
> have pine as their shell and they get scared when the connection drops.
>
> I use the following recipe to remedy the problem without restarting the whole
> thing:
>
> 1) Check to make sure the lmtp (or deliver) process is stuck because it is
> waiting for an exclusive lock. This will also give you the file descriptor of
> the stuck process.
>
> # strace -p <PID of stuck LMTP process>
>
> 2) Find the file it is stuck on.
>
> # lsof -p <PID of stuck LMTP process> | grep <FD number>u
>
> 3) Once you have the file check which processes have that file open.
>
> # lsof | grep <file> | awk '{print $2}' | sort -n | uniq | xargs ps -e
>
> 4) That will give you a list of processes. I usally find the oldest one
> (look at the date field reported by ps) which has always been an imapd process
> and kill that. After doing this, the rest of the processes will be able to
> grab the exclusive lock and finish what they were doing.
>
> The good thing about doing that is that you're not disconnecting *everyone*.
> The bad is that I heard complains that the same message will appear more than
> once (my guess is that sendmail runs the queue and spawns another lmtp).
>
> I still don't know why this is happening in the first place though. I recently
> compiled 2.0.16 with -g so I can attach gdb to a stuck process and figure out
> whats freezing it. Also I configured the new 2.0.16 with fcntl instead of
> flock which I hope is the reason -- no idea though.
>
> If anyone has any other thoughts, I'd love to hear.
>
> --
> /// max kalika
> // [EMAIL PROTECTED]
>
> "and after a while you'll stop making computers out of stuff and start making
> stuff out of computers" -- douglas adams 4/5/01
