On Thu, 02 Nov 2000, Anthony Towns wrote: > On Thu, Nov 02, 2000 at 12:35:48AM -0200, Henrique M Holschuh wrote: > > No. Maintainer scripts calling /etc/init.d/foo would not be allowed anymore > > in any circunstances, and there is no reason to allow any exceptions: one > > would only need to use invoke-rc.d --force instead, if one must. > > Why would you want to do invoke-rc.d --force instead of just > /etc/init.d/foo restart? If invoke-rc.d does something better than just > using /etc/init.d/foo directly, then it'll get used because it does > it better, there's no need to demand people use the new way even when > there's no benefit. Because there is no guarantee that a non-sysv initscript system will work 100% right if the /etc/init.d files are called directly. One of the benefits of invoke-rc.d is abstracting the initscript-call layer so that deploying such initscript systems is not impossible, just difficult :-P Also, invoke-rc.d --force will warn the user if any of the user's policy rules are being violated... and last (because it is the least important reason :-) ), because the policy diff says you MUST use invoke-rc.d (if you want to change that to a "should" when invoke-rc.d --force would be used, that's something else entirely... but please don't do that unless there's a real need). invoke-rc.d also has one extra advantage if it is the single point of access to run the initscripts: One could easily fire up a text editor and add initscript accounting (why? don't ask me, I don't need it), add a syslog-every-initscript-call trace... > > The problem can be summed up as: We cannot detect whether a service is > > running or not, and we know a maintainer thinks leaving the service alone is > > not wise. However, we MUST avoid starting the service if it is not running > > already, therefore "restart" cannot be used. > > We *MUST*? Really? Yes, if you want the crap that happens when one tries to use runlevels for something in debian and run an upgrade in a non-enable-all runlevel to stop. The same goes to chrooted installs, where one has to fight damons trying to bind a port it's non-chrooted version already did as an additional 'bonus'. We could very well leave the service alone (like you suggest), and we could stop it (like I suggest). We cannot allow it to be started: that is a bug, and a very annoying one at that. > The main reason I've seen people complain is not that we restart services > that have been manually stopped, it's that we even restart services > when they're not running and they're specifically disabled in whatever > runlevel we're currently in. [0] Yes. We must not call "/etc/init.d/foo start" (and "/etc/init.d/foo restart" because that's the same as "start" in the end) if foo is out-of-runlevel. Why are we discussing this? We both agree on this point! > > We attempt to maybe-restart the daemon. If it suceeds, that takes care of > > our problem (maybe-restart only restarts an already-running service). If it > > fails, what should we do *by default*? > > maybe-restart isn't really an option, no scripts implement it. No, but any services which might benefit from it will, given the proper amount of maintainer prodding by users who need it. maybe-restart is defined in the policy proposal because it's a good thing to have, and the only sane way to fix the restart problem in certain situations (this is valid even if we go with your suggestion for the 'restart' fallback issue instead of mine). BTW, calling maybe-restart instead of restart right now is exactly what you suggested: do nothing instead of calling restart. And it wouldn't even have required the time I spent coding multiple fallback actions to implement the "maybe-restart else stop" solution (multiple fallback actions are useful for policy-rc.d anyway, so that time will not go to waste). > It also doesn't really solve a particularly interesting problem. If an > admin wants to stop a script so that it stays stopped, he can edit the > runlevel. If he doesn't do that and it gets restarted by an upgrade, Or chmod -x the initscript for that matter (ugly, but most effective). > I don't think maybe-restart not existing is much of a problem at all. If it existed, and if EVERY instance of restart in maintainer scripts was changed to maybe-restart, I'd not have gotten pissed off by enough #@$#@ daemons starting when they shouldn't to write invoke-rc.d in the first place (even if invoke-rc.d does much more than fix this particular bug). > > I think that, given that a maintainer already asked the service NOT to be > > left alone, stopping it is safer. You think that leaving the service running > > is safer. I want you to give me an example of a likely situation where > > stoping the out-of-runlevel daemon would be worse than leaving it alone, so > > as to better understand your point. > > An admin doing remote administration over ssh in single user mode (I don't > know how they'd quite manage this in the first place, maybe J. Random > Clueless On-Site Tech Support person managed to type /etc/init.d/ssh > start after putting it in single user mode to let a remote admin log in > to work out wtf is going on). If /etc/init.d/ssh start will work in single-user mode, then /etc/init.d/ssh stop will NOT kill any active ssh sessions due to the sshd fork model (and if fork doesn't work in single user mode, sshd won't work either). I use that feature all the time to upgrade sshd remotely. I've located and reviewed ALL instances of restart being called by maintainer scripts in my system, and none would result in dangerous behaviour (I don't consider a crash 'dangerous behaviour' in this case) if the daemon is left alone. inetd is the only one I'd be concerned with, and I'd probably fix the issue by coding maybe-restart for it as I don't know what is worse: stopping it in a runlevel it should not be running, or not restarting it in a security update done in a runlevel it shouldn't be running anyway. Very well, I will take the stop out, if only because the problem scenario is unlikely anyway, both solutions are nearly equaly bad and still better than what we have now, and I am too tired to care about it anymore (it's 3am here). I'll regress-test invoke-rc.d tomorrow and post the new version to the list. A "restart" out-of-runlevel now maps to "maybe-restart" (which will mean do nothing 99.9% of the time, I bet. But that 0.1% may be critical for security reasons or something like that). > [0] Actually it's not even that. It's that there's no way to stop a service > from being automatically restarted, whether by manipulating runlevels > or something else. invoke-rc.d in all maintainer scripts + policy-rc.d can fix this problem, thankfully. -- "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:
pgpfV0fb8cnYU.pgp
Description: PGP signature