Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable

Jesse Smith jsmith at resonatingmedia.com
Thu Apr 11 14:54:08 BST 2019

>> When update-rc.d calls insserv, the rcN.d directories are rebuilt
>> without taking into consideration any adjustment that might have
>> been set up locally.  That seems to be done on the assumption that
>> the dependencies coded in the LSB blocks are universally accurate.
>> Now, LSBs are a great improvement over numeric priorities, but to
>> hamper local system tuning, which is not necessarily related to
>> LSBs, IMHO is an insult to the legendary versatility of SysV init.
> I believe it is not how things work now. Last time I checked, call
> `insserv foo` does not update any links to `foo' if there is already at
> least one of them.
> @Jesse, am I right?

I just ran a quick test and can confirm that if I have an existing link
to a service, for example /etc/rc5.d/S05bluetooth, then running the
command "insserv bluetooth" will attempt to remove the old symlink and
replace it with one that conforms to the LSB headers. In my case,
removing the original link and creating /etc/rc5.d/S04bluetooth.

Now, as to whether this should be considered a bug or a desired effect
is open to debate. On the one hand it is understandable people might not
want insserv to overwrite their changes. On the other hand, in my case
insserv is fixing a mistake in my symlinks, and adjusting them to match
their LSB headers.

My thought on this is if someone wants to improve their start-up routine
it makes more sense for them to edit their script's LSB header and
re-run insserv rather than editing links by hand.

More information about the Debian-init-diversity mailing list