On Thu, Nov 02, 2000 at 12:35:48AM -0200, Henrique M Holschuh wrote:
> > > I am worried about packages which do /etc/init.d/foo restart when foo isn't
> > > even a service they provide. For those situations, stop seems to me like a
> > > safer *default* behaviour than ignoring the request. The service is given a
> > > fair chance (in the new code) to avoid a stop if out-of-runlevel, it just
> > > needs to implement maybe-restart.
> > This could be done with:
> > if [ -e /etc/init.d/foo ]; then
> > /etc/init.d/foo stop
> > invoke-rc.d foo start
> > fi
> No. Maintainer scripts calling /etc/init.d/foo would not be allowed anymore
> in any circunstances, and there is no reason to allow any exceptions: one
> would only need to use invoke-rc.d --force instead, if one must.
Why would you want to do invoke-rc.d --force instead of just
/etc/init.d/foo restart? If invoke-rc.d does something better than just
using /etc/init.d/foo directly, then it'll get used because it does
it better, there's no need to demand people use the new way even when
there's no benefit.
> The problem can be summed up as: We cannot detect whether a service is
> running or not, and we know a maintainer thinks leaving the service alone is
> not wise. However, we MUST avoid starting the service if it is not running
> already, therefore "restart" cannot be used.
We *MUST*? Really?
The main reason I've seen people complain is not that we restart services
that have been manually stopped, it's that we even restart services
when they're not running and they're specifically disabled in whatever
runlevel we're currently in. [0]
> We attempt to maybe-restart the daemon. If it suceeds, that takes care of
> our problem (maybe-restart only restarts an already-running service). If it
> fails, what should we do *by default*?
maybe-restart isn't really an option, no scripts implement it.
It also doesn't really solve a particularly interesting problem. If an
admin wants to stop a script so that it stays stopped, he can edit the
runlevel. If he doesn't do that and it gets restarted by an upgrade,
it's no great loss. The only case where running a service is bad is if
it's a security risk of some sort, in which case it's not unreasonable
to expect the maintainer to go to some effort to disable it. IMO. So
I don't think maybe-restart not existing is much of a problem at all.
OTOH, stopping a service that's currently running can be dangerous,
if it stops ssh, or something. Which is why I think standard behaviour
probably shouldn't be to worry about stopping running services just
because they "shouldn't" be running.
Which would mean:
script shouldn't be running in this runlevel:
start, stop, restart -> no op
script should be running in this runlevel:
start, stop, restart -> start, stop, restart
> I think that, given that a maintainer already asked the service NOT to be
> left alone, stopping it is safer. You think that leaving the service running
> is safer. I want you to give me an example of a likely situation where
> stoping the out-of-runlevel daemon would be worse than leaving it alone, so
> as to better understand your point.
An admin doing remote administration over ssh in single user mode (I don't
know how they'd quite manage this in the first place, maybe J. Random
Clueless On-Site Tech Support person managed to type /etc/init.d/ssh
start after putting it in single user mode to let a remote admin log in
to work out wtf is going on).
Cheers,
aj
[0] Actually it's not even that. It's that there's no way to stop a service
from being automatically restarted, whether by manipulating runlevels
or something else.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgp2GzWSjisvJ.pgp
Description: PGP signature