From owner-cvs-etc  Mon Jun  2 18:33:42 1997
Return-Path: <owner-cvs-etc>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA26049
          for cvs-etc-outgoing; Mon, 2 Jun 1997 18:33:42 -0700 (PDT)
Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA26038;
          Mon, 2 Jun 1997 18:33:34 -0700 (PDT)
Received: from awfulhak.demon.co.uk (localhost [127.0.0.1])
	by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id CAA19996;
	Tue, 3 Jun 1997 02:05:05 +0100 (BST)
Message-Id: <199706030105.CAA19996@awfulhak.demon.co.uk>
X-Mailer: exmh version 1.6.9 8/22/96
To: Adam David <adam@veda.is>
cc: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=),
        cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-etc@freebsd.org
Subject: Re: cvs commit: src/etc rc 
In-reply-to: Your message of "Mon, 02 Jun 1997 22:27:07 -0000."
             <199706022227.WAA10666@veda.is> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 03 Jun 1997 02:05:05 +0100
From: Brian Somers <brian@awfulhak.org>
Sender: owner-cvs-etc@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

[.....]
> I have also seen stale locks, but not on a healthy system.
> (file claims to be locked, but no process holds the lock).

Sounds like a *very* sick system.  One that's likely to be
doing other stupid things like SEGVing things for no reason
'cos the descriptor tables are shagged.

> > Modification of each such application is not acceptable solution.
> 
> Each such application already uses its own methods, which are demonstrably
> deficient in many cases.

What we need is a set of calls in libutil:

int pfile_create(const char *prog);           /* create a pid file, return fd 
*/
void pfile_destroy(int fd);                   /* remove a pid file */
pid_t pfile_read(const char *prog);           /* Get pid from file */

And maybe a program that uses pfile_read for use in scripts.

As has already been said, the existence of a lock on an existing
file says whether the process is running or not.

Of course to cater for all eventualities, we may need a "max"
arg in pfile_create and an "n" arg in pfile_read, allowing
more than one of a given process.  Or maybe this is over-
complicating things.

If programs want to use this mechanism, they can.  Killers
like newsyslog should extract the pid to kill using pfile_read,
therefore disabling it from killing un-cooperating processes
(pfile_read will come up with nothing from a stale file).

> --
> Adam David <adam@veda.is>
> 

-- 
Brian <brian@awfulhak.org>, <brian@freebsd.org>
      <http://www.awfulhak.org>
Don't _EVER_ lose your sense of humour....