On Fri, 17 Nov 2000, Anthony Towns wrote: > On Thu, Nov 16, 2000 at 02:19:50PM -0200, Henrique M Holschuh wrote: > Well, really they wouldn't even need to read the docs; it should be obvious > from what gets displayed on screen as to what's happening. Either: > Restarting foo daemon: foo. > or > Not restarting foo daemon as it is not running. > or possibly nothing at all (indicating nothing happened). Hmm.. the messages above are for 'restart-if-running', no? I have a sample implementation using start-stop-daemon that outputs something quite close to that. > I'm not quite clear on what the fallback thing is for, in general, The fallback thing is there only because of policy-rc.d. It allows you to map all start requests of nfs-* to stop, for example... should you need to. Without fallbacks, policy-rc.d would be a limited solution. > actually. For restart/restart-if-running it's something of an > attempt to DWIM (if I say "restart" out of runlevel, I probably mean > "restart-if-running", so do that) but I don't see what other uses it > could have... Any examples spring to mind? Well, yes. There is a *long* standing request to block ALL daemon starts on package installs, requiring the local administrator to actually enable a service before it can be started. This could be done without fallbacks (since it's just a simple deny), but it is what inspired me to add policy-rc.d. Since I didn't want to have all that trouble to add a policy layer that could do denies and later hear someone complaining that he couldn't force all restart to stops or something like that, I designed the complete solution. I imagine someone could want to make sure a daemon is never ever started or left running in a chroot jail, and map all requests for all daemons to stop, or something like that. And there is the DWIM restart -> restart-if-running (and if that fails, 'stop') possibility, as well. You could say I took a "I don't want to hear what the Tcl guys heard" approach when designing this thing... but still, it is done, it is tested, and it works. If nobody ever needs it, it will remain unused. If someone ever needs it, it's there. > > Would a single line invoke-rc.d warning before it attempts to do something > > involving fallbacks do? > > I don't see why it would be necessary or useful, but that may be failure > of imagination on my part. Well, it doesn't take a policy change to fix that later, should one line be still one too many. I'll reduce it to one line, and if it ends up being too verbose, you (or anyone else) can request it to be changed, all it will take is a wishlist bug report to the sysvinit (and file-rc, I suppose) packages. If the maintainer of the sysvinit package thinks you're right, he'll do the change. > Well, I'd have just called "--disclose-deny" "--verbose", but I think > this matches what I was thinking. Except that I'm not clear on what Ok. Will implement it, then. FYI, --disclose-deny causes a different return status to be sent back if a deny happens. Otherwise, invoke-rc.d returns 0 when it denies an action. --disclose-deny pretty much means the calling script does care about what is happening with the service, so a warning message seems wise (the script would have used --query if it wanted to probe what would happen, without causing warning messages to be sent). > other cases (than the restart/r-i-r one) this would apply to. All of them. Unless whatever the user have for a policy-rc.d likes to talk too much, but that's outside our control. > It's undefined in all existing init scripts, no matter what policy says. > It could, legitimately, equate to "restart" because it just ignores > everything after the first bit it matches, output an error message, > return successfully without an error but doing nothing, or do something > completely random. Fortunately, that's not what happens. A few scripts ignore the entire action argument, but I couldn't find any that does something as weird as matching on restart*. Besides, we will need to face this issue sooner or later. Either because of restart-if-running, or because of "status" or something else. We should allow extensions to be deployable. Initscripts must be made to act sanely if given unexpected actions... we might as well do it now while there are very few that are bad behaving, and someone (me) is offering to do the dirty work if the maintainers of the affected packages don't feel like it. [...] > That might be a better explanation of what I'm trying to get at. It is, but I had gotten your point already. I am not sure if I'm willing to accept that we simply cannot ever extend the initscript interface, instead of repairing the damage, though. As I said, I am willing to go along with a mere 'should' deprecating "restart" for initscripts that define 'restart-if-running', even if I don't think that's the absolutely best possible solution. > > 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 > > Well, that's never been in policy as far as I can tell. So I really It should be, and we might as well get it in now, IMHO. I've already explained why (to allow future extensions). I'll put it in the 'restart-if-running' policy proposal, or as a stand-alone one (invoke-rc.d has nothing to do with it). Is that ok with you? > unknown arguments the same as start. Error output goes variously to > stdout and stderr. It's a lovely mess, isn't it? :-) Well, I won't even try to touch the stderr/stdout issue before I see what the LSB guys will try to push on us. And maybe I won't want to touch it then, either. > > 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. > > That's not quite enough: you'd have to make it mandatory for all scripts > that might be invoked with an invoke-rc.d that does fallbacks, whether > they're new or old. Hmm? "All the scripts that might be invoked with invoke-rc.d (that does fallback or not)" is the same set as "all initscripts that get registered through update-rc.d", which is the only subset of 'all init scripts' that packages not implementing an initscript system are supposed to touch. I am not sure I understand what you mean. So, one makes mandatory in (the restart-if-running change to) policy that for every policy-defined initscript actions (be them mandatory or optional), an initscript must not ever do anything else than what's defined in policy for that action. Futhermore, any actions not implemented by an initscript must cause it to fail with a non-zero status code. This allows for expansions of the initscripts in a sane way. [...] > I can think of two ways of achieving this: > > (a) Make invoke-rc.d behave exactly like calling the script by > hand, except that when out of runlevel it maps: > start -> no op > restart -> stop / no op > stop -> stop / no op (matching the above) > reload / force-reload -> reload/force-reload (?) / no op > (I'd be inclined to mapping them all to no ops, personally) And I'd map them to stop. The default will remain no-op, and if it bothers me I can just dump the following into /usr/sbin/policy-rc.d: #!/bin/sh if test "$1" = "restart" ; then echo "stop" exit 106 fi exit 0 Or even use echo "restart-if-running stop" since I personally don't mind the error message (this translates to restart-if-running || stop). Here's a good reason for implementing the fallback engine: Choice :-) > (b) Make invoke-rc.d behave like the above, except that when > out of runlevel it maps: > restart -> restart-if-running || stop > and require all scripts that use invoke-rc.d to implement > restart-if-running correctly. Correctly as either "exit 1" > with no error messages, or doing what it's meant to do. > > If restart-if-running's not implemented correctly, calling invoke-rc.d foo > restart will give nonintuitive behaviour. Yes. However, as it was in my original proposal, it *did* explain what it was happenning, so it would be "non-intuitive" (because it generates an error message) but it wouldn't puzzle the user. > It just seems to me that (b) is more complicated and harder to make use > of (you can't just search and replace, you have to do actual code if > you want to use invoke-rc.d), and isn't really any better than (a). I'd go with a) too, given the "no error messages" bit you have in b. I still think that (as long as the 'might do something else' problem with restart-if-running is solved), an error message is an acceptable price, so as one doesn't have to write the 'actual code' b) requires. > 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 > never actually use /etc/init.d/foo blah-if-running, and they accidently > screwed it up, this increases the annoyance it can cause without making > it any easier to detect in the first place. or something like that). There's no helping that. If restart-if-running is made mandatory in any way (be it a silent exit, or implementing the action), people will have to edit their initscripts. 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 want to get this thing done and seconded before I propose restart-if-running... that's why I aggreed to split the proposals in the first place, so that we could get what's more important (invoke-rc.d) deployed sooner. -- "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:
pgp1Pk37SoVxe.pgp
Description: PGP signature