Bug#743274: insserv: warns about configuration changes

Dolphin Oracle dolphinoracle at gmail.com
Sat Jul 20 01:32:42 BST 2019

I think 2 makes a lot of sense.

On Fri, Jul 19, 2019, 8:27 PM Jesse Smith <jsmith at resonatingmedia.com>

> This is an interesting issue. I think this is what is happening:
> 1. update-rc.d wants to disable the osspd service. To do this is creates
> a file called /etc/init/osspd.override.
> 2. update-rc.d then calls insserv. insserv sees that the osspd script
> normally starts in runlevels "2 3 4 & 5", but there is an override in
> place preventing the script from starting.
> 3. insserv then warns about the situation, to let the user know osspd's
> default runlevels have been altered.
> What makes this tricky, in my mind, is that if insserv were run as a
> stand-alone program from the command line, it would be entirely correct
> to warn the user that a script's defaults were overridden and its
> behaviour changed. If I were to simply run "insserv" on its own, this is
> what I would want.
> But in this case the update-rc.d script is calling insserv, insserv
> isn't being run stand-alone. Since we just told update-rc.d to disable
> osspd, and we want that override behaviour, the warning seems entirely
> out of place.
> In other words, I believe both update-rc.d and insserv are behaving
> correctly, and this would be proper behaviour if insserv were run on its
> own. The problem is mixing the two together.
> I have two suggestions to improve the current behaviour:
> 1. update-rc.d can be edited to catch the warning. Piping output from
> insserv and running it through sed or grep would avoid warnings about
> scripts update-rc.d had just changed.
> 2. We can add a quiet/silent flag (maybe -q) to insserv. When that flag
> is present, the program does not print out warnings. We would still
> print serious errors, but not minor warnings for override situations.
> Then the update-rc.d script can just call "insserv -q" to avoid extra
> output like this.
> I'm open to feedback but I think #2 is probably the best way forward for
> everyone. Thoughts?
> - Jesse
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20190719/aa60ab98/attachment.html>

More information about the Debian-init-diversity mailing list