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

Bug#76868: invoke-rc.d proposal)



On Fri, 17 Nov 2000, Anthony Towns wrote:
> On Thu, Nov 16, 2000 at 02:19:50PM -0200, Henrique M Holschuh wrote:
> 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).

Hmm.. the messages above are for 'restart-if-running', no?  I have a sample
implementation using start-stop-daemon that outputs something quite close to
that.

> I'm not quite clear on what the fallback thing is for, in general,

The fallback thing is there only because of policy-rc.d. It allows you to
map all start requests of nfs-* to stop, for example... should you need to.
Without fallbacks, policy-rc.d would be a limited solution.

> 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.

Since I didn't want to have all that trouble to add a policy layer that
could do denies and later hear someone complaining that he couldn't force
all restart to stops or something like that, I designed the complete
solution. I imagine someone could want to make sure a daemon is never ever
started or left running in a chroot jail, and map all requests for all
daemons to stop, or something like that. 

And there is the DWIM restart -> restart-if-running (and if that fails,
'stop') possibility, as well.

You could say I took a "I don't want to hear what the Tcl guys heard"
approach when designing this thing... but still, it is done, it is tested,
and it works. If nobody ever needs it, it will remain unused. If someone
ever needs it, it's there.

> > 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.

Well, it doesn't take a policy change to fix that later, should one line be
still one too many. I'll reduce it to one line, and if it ends up being too
verbose, you (or anyone else) can request it to be changed, all it will take
is a wishlist bug report to the sysvinit (and file-rc, I suppose)
packages. If the maintainer of the sysvinit package thinks you're right,
he'll do the change.

> 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

Ok. Will implement it, then. FYI, --disclose-deny causes a different return
status to be sent back if a deny happens. Otherwise, invoke-rc.d returns 0
when it denies an action. --disclose-deny pretty much means the calling
script does care about what is happening with the service, so a warning
message seems wise (the script would have used --query if it wanted to probe
what would happen, without causing warning messages to be sent).

> other cases (than the restart/r-i-r one) this would apply to.

All of them. Unless whatever the user have for a policy-rc.d likes to talk
too much, but that's outside our control.

> 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.

Fortunately, that's not what happens. A few scripts ignore the entire action
argument, but I couldn't find any that does something as weird as matching
on restart*.

Besides, we will need to face this issue sooner or later. Either because of
restart-if-running, or because of "status" or something else. We should
allow extensions to be deployable. Initscripts must be made to act sanely if
given unexpected actions... we might as well do it now while there are very
few that are bad behaving, and someone (me) is offering to do the dirty
work if the maintainers of the affected packages don't feel like it.

[...]
> 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.

As I said, I am willing to go along with a mere 'should' deprecating
"restart" for initscripts that define 'restart-if-running', even if I don't
think that's the absolutely best possible solution.

> > 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

It should be, and we might as well get it in now, IMHO. I've already
explained why (to allow future extensions). I'll put it in the
'restart-if-running' policy proposal, or as a stand-alone one (invoke-rc.d
has nothing to do with it). Is that ok with you?

> unknown arguments the same as start. Error output goes variously to
> stdout and stderr.

It's a lovely mess, isn't it? :-) Well, I won't even try to touch the
stderr/stdout issue before I see what the LSB guys will try to push on us.
And maybe I won't want to touch it then, either.

> > 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.

Hmm? "All the scripts that might be invoked with invoke-rc.d (that does
fallback or not)" is the same set as "all initscripts that get registered
through update-rc.d", which is the only subset of 'all init scripts' that
packages not implementing an initscript system are supposed to touch. I am
not sure I understand what you mean.

So, one makes mandatory in (the restart-if-running change to) policy that
for every policy-defined initscript actions (be them mandatory or optional),
an initscript must not ever do anything else than what's defined in policy
for that action. Futhermore, any actions not implemented by an initscript
must cause it to fail with a non-zero status code.

This allows for expansions of the initscripts in a sane way.

[...]
> 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)

And I'd map them to stop. The default will remain no-op, and if it bothers
me I can just dump the following into /usr/sbin/policy-rc.d:

#!/bin/sh
if test "$1" = "restart" ; then
   echo "stop"
   exit 106
fi
exit 0

Or even use echo "restart-if-running stop" since I personally don't mind the
error message (this translates to restart-if-running || stop).

Here's a good reason for implementing the fallback engine: Choice :-)

>         (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.

Yes. However, as it was in my original proposal, it *did* explain what it
was happenning, so it would be "non-intuitive" (because it generates an
error message) but it wouldn't puzzle the user.

> 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).

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.

> 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. If restart-if-running is made mandatory in any way
(be it a silent exit, or implementing the action), people will have to edit
their initscripts.

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 want to get this thing done and seconded before I propose
restart-if-running... that's why I aggreed to split the proposals in the
first place, so that we could get what's more important (invoke-rc.d)
deployed sooner.

-- 
  "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

Attachment: pgpWfcFWQ9t4u.pgp
Description: PGP signature


Reply to: