On Tue, 31 Oct 2000, Steve Greenland wrote: > > + `update-rc.d' and the system administrator. Also, requests to restart a > > + service out of its intended runlevels are changed to a stop request. > > The last sentence causes a problem in the following (contrived?) > scenario. > > 1. Daemon foo is not configured to run at current runlevel. > > 2. I, the sysadmin, have started foo by hand. > > 3. I do a apt-get upgrade, which includes a new versin of foo. Because > of "restart converted to stop", foo is stopped. True. The "always right" way would be to make "maybe-restart" mandatory, and use that instead. Actually, I'd much prefer to have "maybe-restart" mandatory instead of optional, but I fear that would be considered too intrusive, as it would require a LOT of non-trivial coding. However, the difficult work required for a mandatory "maybe-restart" will need to be done to implement the LSB "status" mandatory option anyway. So _maybe_ it would be better to just make "maybe-restart" non-optional and be done with it. (Before anyone starts a flamewar over this, READ THE LAST PARAGRAPH OF THIS MESSAGE. Thank you). > I propose that instead of "restarts converted to stops" we just go with > "restarts ignored". I realize that this would cause the new version of > foo to be ignored, but that may be less surprising than having foo go > away completely, I am not sure which one is the lesser of the two evils: ignoring or stopping the daemon :-( I spent some time thinking about that, and I decided that 'stop' was the safer approach, as it is very unlikely that a mission-critical component (e.g.: name service, MTA, coldbeerd, and the PLC supervision daemon for the radioactive-hamster-based thermonuclear-rodent plant in the basement) would need to be left running out-of-runlevel to avoid system (or user ;-) ) meltdown. I can always change the restart fallback to 'maybe-restart' instead, which would give the initscript a fair chance to do something sensible, and then force-feed it a 'stop' if the maybe-restart call returns a non-zero status. This requires some code changes to the invoke-rc.d script, but since a bogus 'restart' is such a common problem with maintainer scripts and runlevels, it might be worth the trouble. I'll do it. > OTOH, if 'maybe-restart' worked even if foo is not configured at the > current run-level (it's not clear to me that it does or doesn't, but I invoke-rc.d itself only enforces runlevel (and policy-rc.d) constrains against the action requested in the command line, so a fallback action would be run regardless of the runlevel. Also, the only actions with built-in deny rules are start and restart. So, yes, as long as policy-rc.d doesn't forbid it, invoke-rc.d would run maybe-restart out of runlevel. > only did quick skim of the descriptions), and packages strongly urged to > use it in the postinst, that would be a better solution. As I said, I'd really like to see the severe problem "restart" is fixed, and "maybe-restart" is my best hope for that. I just don't know if people are willing to finally -have- to code sensible initscripts that do know the (running) status of whatever service they control. It IS a non-trivial thing to code (safely) at best if the daemon doesn't cooperate. I'd prefer to get this whole invoke-rc.d deal into policy with an optional maybe-restart first to fix the worst mess. After it's in policy, any developer can propose changing maybe-restart to non-optional and we can have the flamewar without endangering the whole initscript fix :-) -- "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:
pgpwUKTUYiNad.pgp
Description: PGP signature