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

[Harald Dunkel]

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 .

Even if you keep Heartbeat out of the loop, the 3rd state is a fact.
Either there is a 'K??*' or 'S??*' symlink, or the symlink is missing.
3 choices.

The point is, that invoke-rc.d and /etc/init.d/rc treat this 3rd choice
in an inconsistent way. invoke-rc.d starts the service, if the symlink
is missing. /etc/init.d/rc doesn't.

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.


>> The problem is that invoke-rc.d and init handle this 3rd state in a
>> different way. This seems inconsistent to me.
> 
> I suspect it is because the third state is 'undefined', not
> 'ignored'. :)
> 

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


Regards

Harri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20090823/ed2a589d/attachment.pgp>