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