Re: Bug#244908: is it OK for invoke-rc.d stop not to stop?
On Wed, 21 Apr 2004, Herbert Xu wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> > --exec should never be used for stop. If you don't have a pidfile, use
> > --name and pray that you don't kill the wrong thing -- the real fix IS to
> > maintain a pidfile properly.
>
> No --name is not a substitute for --exec. Why should you be killing
> random user processes that happen to have the same name and the same
> pid?
Because they happen to have the same pid in the pidfile we expect the daemon
to be, AND are named the same way (supposedly, a non-generic name) as we
expect the daemon to be.
The chances of one killing the right thing when using --name and --pidfile
are much better than when using --exec (and while --exev never kills the
wrong thing, it fails to do its work very often), nowadays.
What you say against --name --pidfile depends on all of the following
situations happening:
- The wrong thing must have the same pid that is in the (correct)
pidfile
- The wrong thing must have the same executable name as what we would
expect out daemon to have (and we are not using a generic name)
- The user started a different executable, that he does NOT want to
control with the initscript, which happens to have the same non-
generic name as what the initscript should be controlling
- The user didn't edit the initscript
To me this looks far fetched, and IMHO it is an operator error.
Please enlighten me if I understood your point incorrectly, or if I missed
something above.
A note that --name is useless if you have generic names in your daemon is
probably a good idea.
> Depending on what daemon this is, the user may well have a legitimate
> reason for running a private copy.
Indeed. That would require editing the initscript for things to work
correctly, wouldn't it? IMHO not doing so is an operator error. At the
very least, any private daemons should not be using the same pidfile as
another instance of the daemon (in fact, any non-broken daemon will refuse
to work if you use the same pidfile and you want to have two instances
running).
> Valid alternatives do exist for --exec, such as Unix sockets, but please
> do not recommend people to replace it with --name --pidfile. It's not
> much better than --pidfile.
It is much better than --exec, which does not deliver the required
functionality.
As for control sockets, they have exactly the same problem as --pidfile
--name if a "private copy" of the daemon is started without it being
properly configured to use another socket location than the default.
The advantage of control sockets is that one can have a daemon with the name
'perl' (amavisd-new does this. Yuck), and still not hit the wrong thing if
we have a stale pidfile left around AND another process named 'perl' happens
to be using the same pid. Most daemons do not require such functionality
to avoid problems, so control sockets are not always "better". And they are
more complex to implement (if they're not already there) than a pidfile.
OTOH, such daemons CANNOT use --exec anyway. Every time 'perl' is upgraded,
the initscript will break (and do notice there is absolutely no way to fix
this while still using --exec, unless we start doing the "libc upgrade hook"
thing for perl, too). In fact, we had a bunch of bug reports against
amavisd-new because of it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: