On Wed, 15 Nov 2000, Anthony Towns wrote: > On Tue, Nov 14, 2000 at 12:06:36PM -0200, Henrique M Holschuh wrote: > If you hide error messages, you'll make it harder for people to notice > bugs in their init scripts when they upload a new package (let's see, > yup, seems to work fine in my postinst, no errors, great!). And receiving > them in normal usage is just messy. Tell that to every maintainer that >/dev/null update-rc.d, not to me. Or better yet, make it a policy proposal. > Errr. Shouldn't the invoke-rc.d: stuff only appear with some sort of > --verbose argument? Well, they're error messages, use --quiet if you don't want them (starting a daemon out-of-runlevel IS an error, even it it is one only invoke-rc.d can detect). If you read the invoke-rc.d script, you'll notice that should nothing wrong happen, invoke-rc.d will not output anything by itself. I could leave the more verbosy stuff that fallbacks cause, but THAT would give quite a lot of room to user confusion. When someone starts the holy war against the amount of crap a upgrade sends to the screen, and AFTER the TeX and emacsen-related packages succumb to said holy war and stop spewing dozens of lines of unneeded info to the screen, I'll remove the slightly verbose fallback messages (which amount to 3 lines, I think) ;-) > It's an unrealistic example, obviously, but I suspect it's still policy > compliant at the moment. I just don't think invoke-rc.d should be doing Sorry, I expect something better than that for an example :-) Don't worry about the policy-compilant angle, once restart-if-running is defined in policy (the definition is normative. It is only adding a restart-if-running to a initscript that is optional), that hole is closed. Now, please lets stop with the nonsense. Please either give me a good reason, or stop complaining. I *know* you don't like the fallback, and obviously, this is NOT enough reason for me to change my mind. So far you have been unable to give me *one* good reason (as in technical reason) to take the fallback out. And may I remind you that once you gave me one reasonably good reason to take the 'stop' out from the original fallback proposal, I did. So, please stop wasting my time. Give me a good reason, or let the thread die, I am not being unreasonable. > > OR if you give me another solution that is workable. > > Don't do fallbacks. For scripts that don't support r-i-r, use: I will assume you mean "do nothing as a fallback". > invoke-rc.d foo restart > > for scripts that do support r-i-r, use: > > invoke-rc.d foo restart-if-running This will only work if I add to the 'restart-if-running' policy proposal that: "should a service support restart-if-running, all _maintainer_ scripts that invoke initscript actions on that service *must* *never* use 'restart'. Use 'restart-if-running' or 'stop' and then 'start' instead, depending on whether the daemon should be left running out of runlevel, or not." Do you think that's better than the fallback? It *is* another solution, and one I am wiling to accept (it fixes all the holes and bugs), but it does mean RC bugs against a number of packages if another package suddenly adds 'restart-if-running'. I think it is more painful than 3 lines of error messages. > . Don't dipslay the "invoke-rc.d:" stuff unless --verbose is specified, > don't hide any errors from the init.d scripts ever. Invoke-rc.d never hides any output from the initscripts (not even with --quiet). It is not against policy to >/dev/null something, if you want to make it against policy to hide errors from stuff like update-rc.d, and invoke-rc.d, go right ahead and propose it. But be warned that a LOT of packages do that in their maintainer scripts. > > Also, do remember that the fallback will only happen in a system > > where the local administrator knows enough about runlevels to change > > Debian's default of 'start service in all runlevels'. > > It'll also happen if the admin changes to single user mode, and then > installs some packages. I could very easily lift the restriction on starting (and restarting -- it's the same thing) stuff in runlevel S (i.e. runlevel S is never 'out-of-runlevel' by default). This is actually a good question, and one I *would* appreciate some opinions about. Hmm... I'm seriously considering adding this, regardless of the whole fallback and 'restart-if-running' issue. Thank you for calling my attention to the issue. As for spliting the proposal, it's obvious that the 'restart-if-running' is going to be a little contentious. Consider the proposal split. I'll follow up with a new policy proposal for 'restart-if-running'. Obviously, all and any mentions and usage of 'restart-if-running' in invoke-rc.d and its interface description are going away *UNTIL* 'restart-if-running' is deemed either accepted or rejected as a policy proposal. Also, if 'restart-if-running' is accepted, I will use it as a fallback for 'restart' in invoke-rc.d, unless I am given a very good reason not to. If invoke-rc.d is already in policy and deployed by that time, the sysvinit and file-rc maintainers will have the last word on the issue. A 'restart-if-running' proposal will be sent to the BTS, shortly. -- "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:
pgpS5K_ucLBpw.pgp
Description: PGP signature