"Scott Miller" <scott(_at_)prc(_dot_)utexas(_dot_)edu> wrote:
A few days ago I setup procmail 3.10 to work from my .forward
there were about 20 procmail processes running waiting to deliver
mail in the mail queue. All the processes appear to be sleeping,
waiting for a lock.
fcntl(8, F_SETLKW, 0x0002FE3C) (sleeping...)
Fetch v3.11pre4 of procmail, compile and install it. This is exactly
the kind of situation the lockingtests (during the compilation) try
to detect and avoid. Apparently they missed this malfunctioning
fcntl() method.
The v3.11pre4 lockingtest have been slightly improved over those
from 3.10. So maybe it will be fixed by simply upgrading, you might
want to make sure that you specify enough relevant test-directories
in de lockingtest. Alternately, you can simply hardwire things to
the known good locking methods on your machine. Check the INSTALL
file.
Is there anyway to kill the procmail processes? How can I tell which
No. They tend to hang in the kernel, unkillable.
process is locking the mail spool? Is there anyway to remove the
There isn't any. More likely, your system lockdaemons went on an
extended vacation (i.e. crashed or similar).
Restart the lockd and rstatd processes on both the NFS client and
server.
offending line from the files in the mail queue?
The sysadmin can edit the mailqueue files.
--
Sincerely,
srb(_at_)cuci(_dot_)nl
Stephen R. van den Berg (AKA BuGless).
Real programmers don't just die, they produce core dumps.