[Pkg-sysvinit-devel] Bug#542811: Bug#542811: Bug#542811: Bug#542811: invoke-rc.d starts disabled

[Henrique de Moraes Holschuh]

On Sun, 23 Aug 2009, Harald Dunkel wrote:
> Petter Reinholdtsen wrote:
> > [Harald Dunkel]
> >> From init's point of view a service can be in one of 3 states in
> >> each runlevel: "enabled", "disabled" or "ignored". "insserv -r
> >> <service>" moves a service to the "ignored" state for all run
> >> levels. For a Linux-HA cluster I need this 3rd state.
> > 
> > Why do you need a 3rd state that is not enabled or disabled for the HA
> > cluster?
> 
> I just want to move a service out of reach of init and invoke-rc.d .

Use policy-rc.d for that.  Note that it will become also out-of-reach for
package maintainer scripts depending on what you do, so kindly remember
that when doing package upgrades/removals/installs.

> Even if you keep Heartbeat out of the loop, the 3rd state is a fact.

The third state is "behaviour undefined", not "ignored".  Don't rely on it.

If you want something to not be touched, use policy-rc.d.

> Looking at the LSB-style headers of the available services it seems
> that there are pretty many services making use of the 3rd choice, e.g.
> udev, alsa-utils, checkfs and checkroot, ...  Surely I do not want to
> break these startup scripts.

On machine shutdown/restart, the behaviour is not undefined, as we SIGTERM
and then SIGKILL anything that is not whitelisted.

> IMHO "undefined" is not the correct word. Removing a service using
> "update-rc.d myservice remove" is very well defined.

It is undefined by the SYSV initscripts implementations.

Now, we can certainly decide that refusing to start (but still honouring
stop or it will cause all sort of crap for package upgrades) is a more
user-friendly way to deal with it, and change invoke-rc.d accordingly.

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