What's the insserv way of disabling services

Michael Biebl mbiebl at gmail.com
Wed May 7 10:48:12 UTC 2008

2008/5/7 Kel Modderman <kel at otaku42.de>:
> Hi Michael,
>  On Thursday 17 April 2008 12:27:27 Michael Biebl wrote:
>  > Hi,
>  >
>  > I was wondering, how to correctly disable a service with insserv.
>  >
>  > In the old style way, one would *not* run
>  > update-rc.d $service remove, because that would recreate the symlink on
>  > the next package upgrade, but instead rename the symlinks from S?? to K??
>  >
>  > insserv -r by default removes all symlinks, so a package upgrade will
>  > recreate them.
>  > Renaming S?? to K?? on the other hand doesn't seem to make sense with
>  > insserv, as the priorities are not fixed and maybe confuse insserv when
>  > it calculates the stop priorities.
>  > Besides, manually renaming the symlinks from S to K is cumbersome.
>  >
>  >
>  > Imho insserv should have a option to disable a service completely.
>  > An idea would be to store this information in a state file
>  > /etc/init.d/.depend.disabled.
>  >
>  > insserv -D --disable would disable the service and add it to the state file
>  > insserv -e --enable would enable the service and remove it from the
>  > state file.
>  >
>  >
>  > If a service is disabled,
>  > insserv $service would be no-op.
>  >
>  >
>  > What do you think?
>  I agree with pere that an insserv specific way would probably be less useful
>  than a generic interface for enabling/disabling system services.
>  One thought i had would be a package specific for this purpose, following
>  the specification drafted by Henrique M Holschuh [0,1].
>  such a package could provide /usr/sbin/policy-rc.d which would be the interface
>  for fine grained administration of per service policies. I don't know of any
>  package that installs a /usr/sbin/policy-rc.d file other than the simple one
>  cdeboostrap provides for chroots (exit 101).

That disables the init script altogether, which I didn't have in mind.
My concern are mainly the services that are run during bootup and shutdown.

Pere already posted some ideas to the d-d mailing list.
It is basically about defining an API how to disable a service (using
Remains, how to implement it: Imo it would be cleaner if we would
store the state separately and not indirectly by renaming S?? -> K??
(could be implemented the same way for plain sysv, and really, tools
like sysv-rc-conf already do something like that (see
/var/lib/sysv-rc-conf), just not in a defined way, so they doesn't
play well together with other runlevel editors).

Let's have a file /var/lib/init

disable service:
update-rc.d disable $foo, adds $foo to /var/lib/init removes all
symlinks in /etc/rc?.d/
(with plain sysv, the runlevel information, like runlevels and
start/stop priorities is also stored)

package upgrades:
update-rc.d $foo defaults (start .. stop..) would not create any
symlinks, if $foo is in /var/lib/init

enable service:
update-rc.d enable $foo, removes $foo from /var/lib/init, runs
update-rc.d $foo $parms
case 1.) insserv, no runlevel information is necessary $parms would be
case 2.) plain sysv has to store the runlevel information in
/var/lib/init, $parms would be pulled from /var/lib/init.

These are rought ideas. comments welcome


Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

More information about the initscripts-ng-devel mailing list