Subject: Re: Procmail processes from hell

From: [email-masked] (Stephen R. van den Berg)
Date: Fri, 9 Sep 1994 12:25:46 +0200

Ken Bass <[email-masked]> wrote:
>I've run into problems which has caused my sys admin to demand that I
>remove procmail. Whenever "some problem" occurs on the news server that
>causes incoming mail to have problems, procmail is found to be running
>dozens of procmail processes on the mail server.

>procmail: Terminating prematurely whilst waiting for a kernel-lock

The problem here is the NFS lockd(aemon).  This is exactly why the procmail
installation goes to great lengths to determine what kernel locking methods
are reliable on your system.  Apparently procmail is using a method that
is unreliable at times on your system.

Either specify more lockingtest directories during the installation
of procmail, or explicitly disable known unreliable locking methods in
config.h.

What version of procmail do you use now (procmail -v)?
Since v2.92pre10 or so procmail makes attempts to break hanging kernel
locks (after 17 minutes by default).  This doesn't help if you receive
lots of mail in 17 minutes time, of course, but you can decrease this
grace period to deal with higher mail loads (see the TIMEOUT variable).

>Trying to kill the processes do nothing.

That's because the proper cause of action probably is to restart the
rcp.lockd (only root can do that, and it's not just procmail that needs it).

>  Folder: **Requeued**

If you kill them with SIGTERM, procmail, by default causes the mail to
be requeued.  This means the same mail will be redelivered as soon as sendmail
does the next queue run (within 30 minutes on most systems).  If the rcp.lockd
hasn't been restarted, this causes the same problem to occurr all over again.
What you can try is sending a SIGALARM, this forces a timeout right now.

-- 
Sincerely,                                  [email-masked]
           Stephen R. van den Berg (AKA BuGless).

"To err is human, to debug ... divine."