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

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

On Sun, Jan 04, 2004 at 08:56:07AM +0900, Jun-ichiro itojun Hagino wrote:
> > >   no consideration to multiple daemons,
> >      void
> >      pidfile(const char *basename);
> > 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.
>       s/multiple daemons/multiple running instance of the same daemon/

Yes, that's what I assumed you mean, because the other case of multiple
daemons with different names is known to work.

That's what the "basename" argument is intended for, to be used by multiple
instances of the same daemon so that each one gives a unique pidfile.

E.g. from the /var/run of one of my machines:

lfs_cleanerd:m:|u|3.pid
lfs_cleanerd:s:|u|3.pid

pppd manages the pidfiles correctly, too.  Others have command line options
to select a unique pidfile.

> > >   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.
>       you may kill random victim if dangling /var/run/foo.pid stays.

Sure.  So what?  Under your scheme you may kill random victims if other
processes are started under the same name.

Anyway, this is only an issue if your daemons crash a lot.  Maybe I'm unusual,
but on the machines I have to deal with in production, daemons crashing hasn't
been an issue.  I'll burn that bridge when I come to it.


> > >   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.
> 
>       given that /var/run/foo.pid method works only if there's only
>       one running instance of the same daemon, why do i need to bother
>       with the above example? (with two rtsold)

Well, you claimed your scheme would solve the above example without pidfiles.
If you can't show that it does, we have to assume that, in fact, it
doesn't.

However, your claim that the pidfile method doesn't work with multiple
instances of the same daemon is not only false, it is at odds with reality.
There are multiple daemons in NetBSD that manage multiple pid files for
multiple instances just fine.  See above for examples. 

There's also the example of sendmail which not too long ago started
to record its command line paramters in the pidfile.  That was in part
so that you could correctly restart multiple instances of sendmail without
having to divine from where they were started and what the command line
arguments were.  You would have to provide the same functionality, for
your idea to catch on.  Note that sendmail modifies its argv vector so
that ps(1) can't get at the original command line arguments.

--chris