I think 2 makes a lot of sense. On Fri, Jul 19, 2019, 8:27 PM Jesse Smith <jsm...@resonatingmedia.com> wrote:
> 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 > >
