Re: CVS commit: src/usr.sbin/rtsold

[Christoph Badura <bad%bsd.de@localhost>]

On Sun, Jan 04, 2004 at 04:23:30AM +0900, Jun-ichiro itojun Hagino wrote:
>       there's other reasons i dislike pidfiles.

>       they are not properly locked on creation,

Why is this a problem?  Please provide actual failures that are intrinsic to
the pidfile(3) interface, not theoretical arguments.

>       /var/run needs to be writable,

drwxr-xr-x  2 root  wheel  1024 Jan  3 12:44 /var/run

Is that some newfangled definition of "writable" that I'm not aware of?

>       no consideration to multiple daemons,

     void
     pidfile(const char *basename);

DESCRIPTION
     pidfile() writes a file containing the process ID of the program to the
     /var/run directory.  The file name has the form /var/run/basename.pid.
     If the basename argument is NULL, pidfile will determine the program name
     and use that instead.

Seems, like the "multiple daemons" case is already taken care of in the
interface.  Just specify a unique "basename" argument for each of the
daemons.

>       no consistency guarantee between actual process table,

Am I supposed to believe this is a widespread and serious problem in
practice?  If so, I must have been hallucinating the last 20 years of
using Unix.

>       and more.

Feel free to cite them.  Something not made-up would be useful.

>       if anything, a script that searches and kills
>       "rtsold" would be much better.  or, we could extend kill(1) to take
>       string as an argument and kill process under given name.

Actual ps(1) output would look like this:

root     146  0.0  1.0 1596  1248 ??  Ss   Thu12PM  0:03.18 /usr/sbin/rtsold
root     183  0.0  1.0 1596  1248 ??  Ss   Thu12PM  0:03.18 /usr/sbin/rtsold

Please explain to me, how an extension to kill(1) would help to distinguish
between the two rtsolds and signalling only to correct one.  You answer
should take into account that certain signals are not catchable and how
correct operation is garaunteed in that case.

Of course, you could set the process name to something unique, but that is
more difficult than creating a unique file.

I am also curious as to how your idea solves any of the problems you mentioned
in the mail I am responding to.

--chris