Re: RFC: update-rc.d <script> disable|reenable
Sorry for not mentioning before, please keep me in CC on replies.
On Sunday 21 September 2008 12:53:17 Michael Biebl wrote:
> Kel Modderman wrote:
> > Hi all,
> > This email describes an extension of update-rc.d to provide an interface
> > for disabling and reenabling initscript sysvinit runlevel start links.
> > It contains a patch that is the last in a series of patches submitted to
> > the sysvinit team. After speaking with Petter Reinholdtsen on irc he suggested
> > sending the idea to a wider audience for review and discusion.
> > Another proposed update-rc.d extension is worth a mention too, though it is
> > not described in detail by this communication. It is a proposal for a method
> > providing an interface for maintainer scripts to facilitate change of runlevel
> > scheme on package upgrades.
> > Please have a comment and identify what you think is good and crap.
> >  http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002861.html
> >  http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-September/002865.html
> Imho long overdue, thanks for taking a look at this!
> I haven't looked at  yet, but what happens, if you update a disabled
> init script, will it update the K symlinks too, so when you (re)enable
> the service, that it has the correct priority?
No. Once the admin changes the link scheme, the default state has been changed
and the modification will be preserved.
It is intended as an interface of convenience for a local admin, so that they
do not need to cumbersomely manipulate the symlink farm manually. But as you
point out, it becomes painful when the admin wants to revert to defaults, as
the default configuration no longer exists in suitable form to be easily
> # update-rc.d foo defaults
> # update-rc.d foo disable
> # update-rc.d foo from defaults to start 30 2 3 4 5 . stop 70 1 .
> Would it work like this?
No, but I guess this is leading to the other ideas you've floated on
email@example.com involving link scheme state or defaults being stored
somewhere else on the filesystem, instead of using the link scheme to
> Would it also work together with insserv?
My initial tests lead me to believe that insserv respects symlinks that have
had the S -> K bit swapped, and still manages the sort number dynamically as
service dependencies change.
The from .. to .. api might be a different story, although insserv has a
--defaults option which could possibly provide an analogous interface for
changing runlevel defaults.