Subject: Re: Procmail deliver getting blocked after power failures

From: [email-masked] (Stephen R. van den Berg)
Date: Mon, 6 Mar 1995 20:57:57 +0100

"D.Ashton-Reader" <[email-masked]> wrote:
>We had a series of power failures last weekend that seemed 
>to expose a problem with procmail locking (or somesuch ..)

Actually this exposes a problem with your NFS lockd/statd, apparently
both behaved well enough during the installation of procmail, because
otherwise autoconf would have disabled support for those in procmail.
The power failures caused them to get confused about the state of some
locks.
Fcntl(), lockf() and flock() kernel locks are the key words here.

>(i.e. 'procmail' process seemed to hang) in spite of all lock
>files being removed, and this was repeatable (kill 'procmail'
>process, remove lockfiles, let sendmail try again to deleiver)

>In the end the mail files were copied and re-named back to the
>original (were lock file protection in place etc) to solve it.

>The point is, has anyone any ideas why such blocking can happen
>(I have it so spurious lock files get blown away after 17 mins,
>but may 'zmail' uses some type of non-lockfile locking that
>procmail, even on the NFS server, cannot remove - Any ideas plse?

>From the FAQ that will accompany v3.11:

7. Everything installed just fine, it's just that there are several stale
   _locktst processes which refuse to die.  How do I get rid of those?

        In order to prevent things like this from happening to procmail,
        _locktst tries to determine which kernel locking methods are
        reliable.  Sometimes this triggers a bug in the kernel or in
        your system-supplied lockd; this is good, because _locktst detects
        this and makes sure that procmail will not make the same mistake.
        A side effect is that this sometimes leaves behind some stale
        _locktst processes that seem to be unkillable.

        This usually is the result of a buggy lockdaemon.  In order to
        get rid of the stale processes, ask your system administrator
        to kill and restart the (rpc.)lockd (and perhaps the (rpc.)statd)
        on both the filesystem-client (where you compiled procmail) and the
        filesystem-server(s) (where the lockingtests took place).
        Depending on the OS it might help if you send the offending
        _locktst processes a kill signal before or after restarting the
        lockd again.

        In any case, _locktst just uncovered a bug in your operating system.
        You should contact your system's vendor and ask for a bugfix for
        your lockd.

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

To boldly program, where *no* man has programmed before!