cvs commit: src/lib/libutil Makefile libutil.h pidfile.3 pidfile.c

[Pawel Jakub Dawidek]

On Fri, Aug 26, 2005 at 02:57:30AM -0700, Doug Barton wrote:
+> All that said, and not to throw cold water on Pawel's work here, but I 
+> really am not sure that encouraging the use of pid files in this day and age 
+> is a good idea. IMO it's a bit of an artifact from a different era, and I 
+> would love to see us eliminate the use of pid files altogether. But that's 
+> just me.

Pidfiles are quite ok when you do it right.
Without them it is hard to use automats for sending signals to daemons and
be sure you don't hit some random process.
Of course I'll be glad to hear other solutions.

+> I have a specific concern with the way that I understand the library to work, has the use of FLOCK been tested on NFS mounted /var, and diskless boot scenarios?

Basically daemons on NFS mounted /var/ (without rpc.lockd) are going to
work still, ie. I advice in manual page (in example) to ignore errors
from pidfile_open() other than EEXIST and this is what I did for most of
our daemons.
EEXIST means that daemon is already running, other errors mean that we
cannot create/lock/etc. pidfile for other reasons.

The exception here is cron(8), which used flock(2) before for pidfiles
and exits when it cannot lock pidfile, which means cron will not work
in such environment. I don't know the reason of such behaviour so I
leaved it as it was - any error from pidfile_open() is critical for
cron(8).

We could still add storing PID even if flock(2) fails, which is not
done now.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20050826/3da79529/attachment.bin