On Thu, Nov 16, 2000 at 02:19:50PM -0200, Henrique M Holschuh wrote:
> > > As I said, they're there to avoid confusing the user. If they had no
> > > possible purpose I'd have removed them before invoke-rc.d ever seen the
> > > light of this list :-)
> > I guess I'm not seeing what's confusing about it. If invoke-rc.d is meant
> > to fallback to restart-if-running, that's what the user should expect
> > when invoke-rc.d is called. If they're doing `apt-get install portmap',
> > it seems reasonable for them to (a) expect portmap to be restarted, and
> > (b) not to really care exactly how that happens.
> Well, I don't expect users to read the docs
Well, really they wouldn't even need to read the docs; it should be obvious
from what gets displayed on screen as to what's happening. Either:
Restarting foo daemon: foo.
or
Not restarting foo daemon as it is not running.
or possibly nothing at all (indicating nothing happened).
> Anyway, the whole fallback thing is not
> something I expect users to even know about for a while,
I'm not quite clear on what the fallback thing is for, in general,
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?
> Would a single line invoke-rc.d warning before it attempts to do something
> involving fallbacks do?
I don't see why it would be necessary or useful, but that may be failure
of imagination on my part.
> > > Without the restart-if-running fallback, invoke-rc.d simply says:
> > > invoke-rc.d: initscript action "restart" not executed.
> > I don't think it should even say that. (Well, unless someone's using
> > --verbose)
> Well, what about this: I can make it keep quiet if it should return a zero
> status code (i.e. fail silently since the script that called it doesn't want
> to bother with the action suceededing or not) -- do notice this is will be
> the standard behaviour -- and output the error message if --disclose-deny is
> used?
Well, I'd have just called "--disclose-deny" "--verbose", but I think
this matches what I was thinking. Except that I'm not clear on what
other cases (than the restart/r-i-r one) this would apply to.
> > I don't have a problem with the concept of falling back to
> > `restart-if-running', I just don't like the way it invokes undefined
> > behaviour in existing scripts in (relatively) normal use.
> That's why I took 'restart-if-running' out from invoke-rc.d when I split the
> proposals: if 'restart-if-running' is not in policy, it is undefined.
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.
So calling an existing init script with restart-if-running would be a
bad thing. But a program can't tell the difference between an existing
init script, and an updated one that supports restart-if-running, so
relying on a script to choose when to call restart-if-running (which
is what the fallback situation does), is similarly bad. The only way to
avoid having a program decide when to use restart-if-running is to have
a human decide, which s/he can do when writing the maintainer script
that calls invoke-rc.d by either using "invoke-rc.d foo restart" or
"invoke-rc.d foo restart-if-running".
That might be a better explanation of what I'm trying to get at.
> 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
don't like relying on it. For example, /etc/init.d/chrony has an "e)"
instead of a "*)" as its error case, which means it'll quietly exit
successfully. /etc/init.d/nviboot does likewise, but through omission
rather than accident. /etc/init.d/cron and /etc/init.d/setserial treat
unknown arguments the same as start. Error output goes variously to
stdout and stderr.
> I'll make sure the policy proposal for 'restart-if-running' forbids an
> initscript (that's going to be registered by update-rc.d) to do anything but
> what the policy defines for the start, stop, restart, restart-if-running,
> reload and force-reload actions.
That's not quite enough: you'd have to make it mandatory for all scripts
that might be invoked with an invoke-rc.d that does fallbacks, whether
they're new or old.
> > It's a bug, sure, but I don't think it's one we really need to stress over
> > (ie, "should" and normal severity seem quite enough). Especially since the
> Ok, I can leave with a "should". So you'd rather I toss this into
> 'restart-if-running' as a 'should', instead of the fallback using *one* (and
> only one) line for the error message?
Here's my ideal situation.
* All init scripts implement status or restart-if-running.
* All maintainer scripts switch to using invoke-rc.d
* On upgrade either:
(a) services are restarted if the current runlevel says they should
be running
or (b) services are restarted if they're currently running
Which one happens is either dictated by policy or set by the sysadmin.
I don't think it really matters to anyone which.
and, especially, during the transition to this state:
* No scripts should behave nonintuitively (output error messages where
no real error occured)
I can think of two ways of achieving this:
(a) Make invoke-rc.d behave exactly like calling the script by
hand, except that when out of runlevel it maps:
start -> no op
restart -> stop / no op
stop -> stop / no op (matching the above)
reload / force-reload -> reload/force-reload (?) / no op
(I'd be inclined to mapping them all to no ops, personally)
(b) Make invoke-rc.d behave like the above, except that when
out of runlevel it maps:
restart -> restart-if-running || stop
and require all scripts that use invoke-rc.d to implement
restart-if-running correctly. Correctly as either "exit 1"
with no error messages, or doing what it's meant to do.
If restart-if-running's not implemented correctly, calling invoke-rc.d foo
restart will give nonintuitive behaviour.
It just seems to me that (b) is more complicated and harder to make use
of (you can't just search and replace, you have to do actual code if
you want to use invoke-rc.d), and isn't really any better than (a).
If you don't require everyone using invoke-rc.d to also correctly
implement r-i-r, you end up with nonintuitive behaviour. Actually,
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).
Cheers,
aj
--
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:
pgpcO3A3D5acP.pgp
Description: PGP signature