Discussion:
Bug#743274: sysv-rc: update-rc.d warns about configuration changes ("current ... runlevel(s) ... overrides LSB defaults")
(too old to reply)
Ralf Jung
2014-04-01 09:00:02 UTC
Permalink
Package: sysv-rc
Version: 2.88dsf-51
Severity: normal

Dear Maintainer,

when using update-rc.d to disable automatic startup of a service, I get a warning as follows:

$ sudo update-rc.d osspd disable
insserv: warning: current start runlevel(s) (empty) of script `osspd' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `osspd' overrides LSB defaults (0 1 6).

I tried for some time to fix my init script (I am maintainer of osspd), but as this error
shows up when disabling any service, I concluded that the script is probably all right.
Now I wonder what's going wrong here - judging from the fact that there is a "warning",
something seems to be wrong. But from all I can tell, what update-rc.d (or insserv)
is warning about is that I changed the configuration, which is exactly what I told it to do.
If that's the case, the warning should be removed - it is not worth a warning to tell the admin
that it changed the configuration to no longer match the default, if that's the sole purpose
of the action he just took. Actually, it is very confusing as the admin may think something
with what he just did is wrong.
If however there's something else that this warns about, I'd appreciate guidance how to fix my
script. And maybe the message should be made clearer.

Kind regards
Ralf


-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14.0 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sysv-rc depends on:
ii debconf [debconf-2.0] 1.5.52
ii insserv 1.14.0-5
ii sysvinit-utils 2.88dsf-51

Versions of packages sysv-rc recommends:
ii lsb-base 4.1+Debian12

Versions of packages sysv-rc suggests:
pn bum <none>
pn sysv-rc-conf <none>

-- debconf information:
sysv-rc/convert-legacy: true
sysv-rc/unable-to-convert:
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Jesse Smith
2019-07-20 00:30:01 UTC
Permalink
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
Dolphin Oracle
2019-07-20 00:40:02 UTC
Permalink
I think 2 makes a lot of sense.
Post by Jesse Smith
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.
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
Dmitry Bogatov
2019-07-21 18:50:02 UTC
Permalink
Post by Jesse Smith
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.
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?
I agree on adding `-q' to inhibit warnings.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Jesse Smith
2019-07-21 20:20:01 UTC
Permalink
I have added a silent mode flag for insserv. Running the program with
either "-q" or "--silent" will surpress most warning messages. insserv
will only print fatal errors, when it is about to exit, when in silent mode.

A patch for the new behaviour is attached. Maybe we can get update-rc.d
patched to match the new behaviour.

This change will be available in insserv-1.21.0.

- Jesse

Loading...