2008/5/7 Kel Modderman <[EMAIL PROTECTED]>: > 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 update-rc.d). 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). Idea: 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 "defaults" 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 Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
