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

Bug#76868: invoke-rc.d proposal)



On Thu, 16 Nov 2000, Anthony Towns wrote:
> Despite how it may appear, I'm not doing this merely to be obnoxious. :(

Ok, don't worry.

> On Wed, Nov 15, 2000 at 09:13:10AM -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 (oh, I *do* bitch at people for
not doing it, and I myself try to make sure I did read all possible docs
before asking something but...). Anyway, the whole fallback thing is not
something I expect users to even know about for a while, and I don't want
the error message from the initscript to show there alone (some initscripts
won't even identify themselves in the error message, I think). I can reduce
it to one invoke-rc.d: line only for all not-weird-as-hell cases, though.

Would a single line invoke-rc.d warning before it attempts to do something
involving fallbacks do?

> > > Don't remove them, just make them conditional on a --verbose option.
> > I would, but I want them there in the default case. The idea of fallbacks is
> > not even remotely common (it's not difficult, but nobody else does it), so I
> 
> Maybe there's a reason nobody else does it :)

Well, it's like shooting at a fly with a cannon if you just want to fix the
bugs invoke-rc.d fixes. But I am aiming that cannon at the cruiser over
there, and shooting it while the fly is in the path of the missile :-) 

invoke-rc.d implements something rather useful for some people in that whole
policy stuff, and fixes some annoying bugs while at that (even if I _did_
code the entire thing because I got annoyed at said bugs once too often).

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

This way, 'deny' fallbacks would be silent unless the script calling
invoke-rc.d uses --disclose-deny. I may add a --verbose option yet, but
we're discussing the default 'verbosity' level. Just making sure that's
clear.

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

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 (and all update-rc.d-registered
initscripts in my system will behave just like that, I checked).

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. And make it mandatory to abort with an
error-status if the script receives an unknown action.

There are very few scripts that violate the above, and they're all
rcS.d-only and are trivial to fix (I'll fix them and email the diffs to the
BTS before the restart-if-running deployment if it is approved). These
scripts are never called by any maintainer scripts, though, so there's no
risk of invoke-rc.d ever trying to fallback them.

> >   *  restart out-of-runlevel is now denied (does nothing) by invoke-rc.d.
[...]
> 
> 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?

> update-rc.d all the time; and why people bitch about tex and emacs
> upgrades (well, one of the reasons...).

Heh :-)

> > Please review the changelog and new policy diff and second them when they
> > arrive in the BTS (just to make sure it doesn't look like you seconded
> > something and then I changed it under your foot).
> 
> Pfft. I may disagree with you how to do it, but I don't think you're
> dishonest or anything.

Oy, that's not what I meant. Just forget what I wrote above, we have better
stuff to argue about :-)

-- 
  "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: pgpy8GSV2lzNN.pgp
Description: PGP signature


Reply to: