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

Bug#76868: invoke-rc.d proposal)

On Wed, 22 Nov 2000, Anthony Towns wrote:
> 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).

This is what I'd recommend for someone playing around with invoke-rc.d in
chroot jails, actually.

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

Anyone who plays in chrooted installs should be aware of this issue,
anyway... and configure invoke-rc.d (through policy-rc.d) to archieve the
safest behaviour for his particular setup.

People doing weird stuff with policy-rc.d are on their own, though. If they
end up with their MTA/nis/nfs stopped for long periods, it is their fault.

> > > It's undefined in all existing init scripts, no matter what policy says.
> > 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

Well, I don't like the current way :-) It is NOT extensible in a failsafe
way by any means. restart-if-running is an example of a good thing that
might be unusable because of this.

So, no, I don't think we have "coped quite well". I think we deribelately
tried to keep as far as the mess as we could, and this is probably one
reason why it took so long for someone to step up and try to implement
something like invoke-rc.d.

But this is something to discuss in another policy proposal :-)  Care to
start a new thread in -policy or -devel? cc: me, and I'll happly move this
discussion there...

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

Initscripts are an exported interface. Admins are supposed to interact with
them in day-to-day life (although the less they need to, the better). The
loose definition for this interface has been causing some (small) grief for
a while now (how many times did someone complain that they never know for
sure how 'restart' is supposed to behave?).

Again, I think we should move this part of the discussion to a new thread,
and out of the BTS :)

> I don't think you've got my point though. There is no "damage": everything

I did, too :-P  You don't want me to call restart-if-running because we can't
really predict what it'll do as things stand right now. The error messages
are just some minor annoyance and not the real reason you didn't like the
restart-if-running fallback.

I happen to think "the way things stand right now" is very undesirable (not
that I can't use restart-if-running, but the fact that no initscript
extension can ever be deployed in a less troublesome way then a
mass-conversion).  THIS is the damage I'm talking about...

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

Heh, if my users were clueful enough to actualy come close to thinking that
upon such an error message, I'd not be worried. Such an user will probably
RTFM before asking, and say "ah, that's why it did that" upon reading the
invoke-rc.d man page (even if he doesn't agree it was an intelligent thing
to do, but at least now he can curse the stupidity of others (mine?) while
being "in the known" :-P ).

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

That's a risk people willing to use fallbacks need to be able to deal with.
I *would* expect a script to act somewhat weirdly if I remap stop to start
:-) On the other hand, maintainers are only required to test for the cases
defined in policy and other normative documentation (right now, no-ops in
the proposal). Everything else, they have only to deal with if a bug report
shows up.

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

Actually, Manoj said he might second the proposal after reviewing it again.

I'll post another 'changelog' with the final state of the invoke-rc.d
proposal, and ask for seconds.

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

Reply to: