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