[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#76868: invoke-rc.d proposal)



On Sat, Nov 18, 2000 at 01:00:04PM -0200, Henrique M Holschuh wrote:
> > actually.  For restart/restart-if-running it's something of an
> > attempt to DWIM (if I say "restart" out of runlevel, I probably mean
> > "restart-if-running", so do that) but I don't see what other uses it
> > could have... Any examples spring to mind?
> Well, yes. There is a *long* standing request to block ALL daemon starts on
> package installs, requiring the local administrator to actually enable a
> service before it can be started.  This could be done without fallbacks
> (since it's just a simple deny), but it is what inspired me to add
> policy-rc.d.

This could be done more effectively, it seems to me, by using invoked-rc.d
without any fallbacks, and with a modified update-rc.d that considers
"defaults" to be Stop in all runlevels. This has the benefit over a pure
invoke-rc.d solution in that the service won't be started without the
admin's explicit action even on the next reboot.

You could also reasonably map all the maintainer scripts invocations of
invoke-rc.d to no-ops in order to just leave all services running during
an upgrade (rather than possibly shutting them down for an extended period,
say).

One possibility might be to map `invoke-rc.d foo stop' to a no-op, and
`invoke-rc.d foo start' to `invoke-rc.d foo restart', so that daemons
like portmap (stopped in prerm, started in postinst) don't stay down for
extended periods, if that's a bad thing. OTOH, this could easily break
the maintainer script's semantics (or the daemon's, even) so it might
not be reliable enough to be useful.

> > It's undefined in all existing init scripts, no matter what policy says.
> > It could, legitimately, equate to "restart" because it just ignores
> > everything after the first bit it matches, output an error message,
> > return successfully without an error but doing nothing, or do something
> > completely random.
> Besides, we will need to face this issue sooner or later. Either because of
> restart-if-running, or because of "status" or something else. 

That's not the case though. We've coped quite well up 'til now by making
sure we *never* use a feature until we *know* it exists. We can do this
because most init scripts are invoked from the maintainer scripts of
the package their in, so they know exactly what's going on; and other
packages can just add the appropriate versioned dependency.

There's no way for invoke-rc.d to know this though, without being
specifically told.

> > That might be a better explanation of what I'm trying to get at.
> It is, but I had gotten your point already. I am not sure if I'm willing to
> accept that we simply cannot ever extend the initscript interface, instead
> of repairing the damage, though.

I don't think you've got my point though. There is no "damage": everything
can be made to work correctly, without any unfortunate error messages,
without any undefined behaviour, without any problems at all. But this
can only happen if invoke-rc.d is specifically told what behaviours
it can reasonably expect a script to support. The easiest, simplest,
and most logical way to do that is for it to be told one behaviour,
and for that to be the behaviour that's used.

Since invoke-rc.d can't tell if any given script will do something
reasonable on "restart-if-running", it's reasonable for it to not try,
and pass the responsibility back to whatever called it; and in almost
all cases, its caller *does* know which arguments are reasonable to use,
and which aren't.

> > > However, initscripts (of the sort that get registered through update-rc.d)
> > > are *not* supposed to go doing weird things if given something else than
> > > start, stop, restart and force-reload.  They're to abort with a non-zero
> > > status and print an error message
> > Well, that's never been in policy as far as I can tell. So I really
> > unknown arguments the same as start. Error output goes variously to
> > stdout and stderr.
> It's a lovely mess, isn't it? :-) 

Well, that's what you expect when you invoke undefined behaviour. Sure,
it won't usually spill your coffee, eat your corn chips, and abduct your
first born, but you never know...

> [...] so it would be "non-intuitive" (because it generates an
> error message) but it wouldn't puzzle the user.

I'd imagine a user asking ``wtf did you bother trying restart-if-running
if it wasn't going to work? don't you even know what you're doing? stupid
program. hope nothing broke.'' Or, at least, that's what I'd probably think
to myself if I saw something like:

	invoke-rc.d: trying foo restart-if-running
	/etc/init.d/foo: unknown argument restart-if-running
	/etc/init.d/foo: valid arguments are start|stop|restart|force-reload
	invoke-rc.d: trying foo restart
	Restarting foo service: foo.

> I'd go with a) too, given the "no error messages" bit you have in b. I still
> think that (as long as the 'might do something else' problem with
> restart-if-running is solved), an error message is an acceptable price, so
> as one doesn't have to write the 'actual code' b) requires.

Sure, but the 'might do something else' problem can only be fixed if you
have a time machine and fix all the fallbacks that might automatically
get used by any script that gets invoke-rc.d'ed. Which doesn't seem too
practical.

> > I guess the real problem is that if you map
> > 	invoke-rc.d foo blah
> > to anything but
> > 	/etc/init.d/foo blah
> > (or a no op), you add another test case for the maintainer (eg, if they
> > never actually use /etc/init.d/foo blah-if-running, and they accidently
> > screwed it up, this increases the annoyance it can cause without making
> > it any easier to detect in the first place. or something like that).
> There's no helping that.

Sure there is: if it always maps to the exact same thing, there's only
one thing to test (this is what happens right now). If it maps to exactly
one thing or a no-op, it's fairly straightforward to make sure everything
works, you just have to test an install where it's not mapped to no op
and you've got complete code coverage, and you have to make sure the rest
of your script makes sense even if the daemon's not running. If it can
map to other options, you've got to do the install two or three times in
different environments to get complete code coverage, and if you don't
a bug in the restart-if-running portion of your init script that didn't
get tested or noticed graduates to making your package uninstallable on
some systems.

> Aj, regardless of the fallback to restart-if-running issue, are we aggreed
> on the last remaining issue for the CURRENT proposal we're discussing, that
> is invoke-rc.d without restart-if-running? [i.e.: Are you ok with
> invoke-rc.d if I reduce the verbosity level of the current code paths (i.e.:
> say nothing unless --disclose-deny or a very severe error happens)?]

I'm okay if you do or if you don't, either way, although I suspect I've
made my preferance clear :) My second still stands, if that's what you're
wondering. Do you need to pester someone else to get two seconds still? I
haven't been paying attention.

Cheers,
aj, looking forward to reassigning a couple of bugs to sysvinit once
    invoke-rc.d is implemented :)

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``Thanks to all avid pokers out there''
                       -- linux.conf.au, 17-20 January 2001

Attachment: pgpSKOb5MaAqQ.pgp
Description: PGP signature


Reply to: