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

[Doug Barton]

Robert Watson wrote:
> 
> On Thu, 25 Aug 2005, John-Mark Gurney wrote:
> 
>>> Something I'd very much like to see is for daemon pid files to start 
>>> being placed in /var/run/<daemon>/<daemon>.pid, as opposed to 
>>> directly in /var/run.  This will allow us to set specific ownership 
>>> on the parent directory for a pid file, so that privilege is not 
>>> required to write out a pid file in a safe place.
>>
>>
>> why not add an rc.subr option to precreate the file with the correct 
>> user?  I was running up conserver, and I decided to run it as a 
>> seperate user, and since I created it as owned by the conserver user, 
>> conserver just opened and wrote to the file..
> 
> 
> We already actually run bind with a pid file in /var/run/named.  I'm not 
> sure we need a whole lot of magic, other than having mtree create the 
> directories for base system components, and packages/ports create them 
> for third party components.

Frankly, the mtree stuff for BIND to do this is a hack, and I would much 
rather see this generalized in a useful way in rc.subr. That way all system 
stuff can just use it, and all ports can use it as they adopt rc.subr style 
startup scripts. This would not be particularly difficult, if there is wider 
interest in this, I can whip up a POC. Given that the rc scripts run as root 
there shouldn't be any permissions problems to overcome. My thought would be 
to simply default the name of the directory in /var/run to be whatever the 
name of the script is, and the file itself to be "pid" as named does it.

My feeling is that we have way too many empty directories created by mtree 
as it is, especially for ports, and I would really hate to continue adding 
to that clutter.

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.

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?

hth,

Doug

-- 

     This .signature sanitized for your protection