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
signature.asc
Description: OpenPGP digital signature
