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

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

On Sun, Jan 04, 2004 at 09:27:09PM +0900, Jun-ichiro itojun Hagino wrote:
> > 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.

>       well, as far as i see the only program that passes non-NULL in usr.sbin
>       is wsmoused. 

That a fully working interface is not often used, doesn't make the interface
non-working, now does it?  Or was there some more subtle point?

>       the question is, even if
>       lfs_cleanerd creates multiple pid file like above, how can a user know
>       which file to use?  

What has that to do with it?  How can a user know which PID to use in your
alternative scheme?  The answer is always the same: external information.
Surely the programs don't know them self, otherwise they would have to be
sentient and/or read the user's mind.

External information is usally a mapping that the user defines for herself
and that the program has no need to be aware of or a mapping defined by
the program (e.g. lfs_cleanerd or pppd).

Anyway, people are running multiple instances of the same daemon on
thousands of Unix machines (and have been for years).  From the
absence of the complaints I figure this isn't a problem in practice.

> > > > >       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. 
> 
>       did i say that i have solved the problem that was not solved with
>       pidfile?  i have been saying that pidfile() call is not really useful,
>       and there's alternative way to do the same thing.

Despite your claims to the contrary, the fact remains that you can observe
working pidfiles for multiple instances of the same daemon on any number
of machines in production.  So, again, the problem *is* solved with pidfile.

And, yes, claiming that you have an alternative way to do the same thing,
is claiming that you have solved the problem that you allege exists with
pidfile.  That is the meaning of "alternative".  If you don't have a solution,
then you don't have an alternative, you have a way of implementing a
subset of the functionality.

And as the sendmail example shows, your alternative still would need
the equivalent of pidfiles.

Of course, you can claim anything starting from a false premise.

>       for intsance, with two rtsold situation, how would you create pid files?

Assuming that I would want to bind the rtsolds to separate interfaces, I
would use rtsold.$ifname.pid e.g. rtsold.fxp0.pid and rtsold.tlp0.pid.
That seems like an obivious mapping scheme to me.  Of course, this ignores
whether it is desirable to do that, but that is not germane to the discussion
because you are claiming a generic deficiency in the pidfile interface that
is not restricted to rtsold.

If I were to run two nameds on the same machine, one for an external view
and one for an internal view, I would probably use named.external.pid and
named.internal.pid.

>       you do not have solution either, and i have never said that i have
>       solved the problem with my proposal.  you are reading between lines
>       too much.

I have given you four examples of a solution by now.  Still claiming that
I "do not have [a] solution either" is extremely rude.

Figuring out the ramifications of a proposal is a valid use of "reading
between the lines", if you want to call it that.


There is one more reason for adhering to the standard interface of having
daemons create pidfiles.  It allows users to figure out the PID of a
daemon with very simple and short code that only reads the first line
of the pid file.  That is extremely useful in systems where storage is
at a premium, e.g. embedded systems.

>       what i dislike about netbsd is that amount of (usually useless)
>       discussion email is much more than the actual improvement in code.

Well, if you are working on code that other people are supposed to use
you have to listen to their wishes and you'll have to learn to accept
that not everything that you call an improvement is seen that way by
your users.

(Not that I would call removing standard functionality and not even
fixing the vaguely alleged to security problem that is supposed to be
connected with this functionality an improvment.)

But now I have to go and update the isakmpd package for the security
fixes that have sneaked in in the last months.

--chris