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

Alessandro Vesely vesely at tana.it
Mon Apr 15 08:14:41 BST 2019

On Sun 14/Apr/2019 12:52:44 +0200 Dmitry Bogatov wrote:
> control: tags -1 +wontfix +moreinfo
> [2019-04-11 10:54] Jesse Smith <jsmith at resonatingmedia.com>
>>>> 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.

I get this:
insserv: There is a loop between service umountnfs and rsyslog if stopped
insserv:  loop involving service rpcbind at depth 3
insserv:  loop involving service umountnfs at depth 2
insserv:  loop involving service gdm3 at depth 1
insserv:  loop involving service sendsigs at depth 2
insserv:  loop involving service networking at depth 7
insserv: exiting now without changing boot order!

I run fixinit instead

>> 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.

Running interactively in some cases may make sense.  Instead, insserv is run
every time one installs a package which includes a daemon, automatically.

Nowadays, stable sort algorithms are really widespread.  Adjusting links
without subverting their existing order is not that hard.

>> 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.
> Thank you Jesse. Sounds reasonable.


> Dear submitter, please consider, whether your issue could be solved by
> editing LSB headers and if not, why.

Loops or other unforeseen circumstances are always possible.  In such cases, it
would still be possible to add or fix unrelated parts of the start-up sequence.

Perhaps this should be turned wishlist, rather than wontfix.

Thank you for the considerable work you're doing on sysv init.

More information about the Debian-init-diversity mailing list