[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#76868: invoke-rc.d proposal)

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

> . 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

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

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

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

Reply to: