At 16:19 2004-11-19 +0100, Sven Schmitt wrote:
That's what I see in the logfile:
procmail: Timeout, was waiting for "/path/to/mbox"
procmail: Forcing lock on "/path/to/mbox"
As said, it happens now and then only. The user in question uses the
default MacOS mailclient. Any ideas what could cause this?
I presume they're fetching mail with the POP protocol? Have you considered
that the POP server isn't closing their connection?
Some POP servers will fail to remove the lock file if the POP connection
isn't closed cleanly, either because the app has a protocol bug and doesn't
post a POP QUIT command, or it actually crashes at the client end - heck,
if the client's net connection goes out problems can ensue. So if the user
has an application failure or other problem while connected to the POP
server, their POP mailbox may remain "open" (locked).
Every sysadmin has heard of users at some ISP or another who can't download
messages with some particular client software, and end up needing their
mailbox manually unlocked or in some cases, certain messages to be purged
(say, via a webmail or shell mail client), so that their desktop client can
then manage to download the rest of their email.
Procmail sees a lockfile as a potential for file corruption, and waits for
the lock to be cleared before it will write to the file.
The next time this happens, BEFORE you kill queued processes and delete
files, check to see what process owns the lockfile (say, using 'fuser
/path/to/file'). If it isn't procmail, then what you have is procmail
doing the right thing: waiting until whatever OTHER process has the file
locked has unlocked it. if it IS procmail, then you need to determine what
about the procmailrc is freezing up - it could be an externally called
app. Enable VERBOSE logging and check the log when the problem reocurrs --
or make a copy of the procmailrc, change paths, and dump a whole lot of
saved email at it to see if you can't manually reproduce the problem
(although there's a good chance that it's some message you won't have saved
if you're killing the waiting processes currently).
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail