I'll keep it in mind next time it happens. It's just odd that it
doesn't happen every time.
Thanks!
Professional Software Engineering wrote:
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
____________________________________________________________
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