Bug#870747: update-rc.d: enabling a default-disabled service fails: "foo Default-Start contains no runlevels, aborting."

[Felipe Sateler]

On Fri, Aug 4, 2017 at 2:32 PM, Daniel Kahn Gillmor
 wrote:
> Package: init-system-helpers
> Version: 1.49
> Severity: normal
> Tags: patch
>
> i have a system service that is disabled by default.  the local
> administrator is expected to do some not insignificant configuration
> (often using tools shipped in the package) before the service can be
> enabled.
>
> This service prefers an empty Default-Start: line, and a full
> Default-Stop: line.  The administrator is expected to enable it with
> "update-rc.d foo enable" when they're ready.

These two are incompatible. `update-rc.d foo enable` means "leave
links as per defined in the Default-Start/Stop lines", thus it won't
work because you have all-stop defaults.

I think you are redefining what Default-Start means. My undestanding
is it means: 'To enable this service, create these links'. Your patch
would turn it into something like: 'These links should be created at
package installation time'. These are not the same, and it is entirely
sane to have a package not install the enable links at install time.

I don't think update-rc.d should codify policy, it should be a dumb
mechanism to alter the symlink farm.

I think the correct fix is #857452, plus changing your init script to
have Default-start: 2 3 4 5.

#857452: update-rc.d: please provide a defaults-disabled option

-- 

Saludos,
Felipe Sateler

Bug#870747: update-rc.d: enabling a default-disabled service fails: "foo Default-Start contains no runlevels, aborting."

[Daniel Kahn Gillmor]

Package: init-system-helpers
Version: 1.49
Severity: normal
Tags: patch

i have a system service that is disabled by default.  the local
administrator is expected to do some not insignificant configuration
(often using tools shipped in the package) before the service can be
enabled.

This service prefers an empty Default-Start: line, and a full
Default-Stop: line.  The administrator is expected to enable it with
"update-rc.d foo enable" when they're ready.

however, this fails with:

foo Default-Start contains no runlevels, aborting.

Even worse, if i set up a systemd .service file for the same service,
with a vendor preset (systemd.preset(5)) disabled to achieve the same
goal, then when the admin manually enables the service with "systemctl
enable foo" then /lib/systemd/systemd-sysv-install just directly
invokes "update-rc.d foo enable" with no extra arguments, which itself
causes systemctl itself to fail.

So fixing this misbehavior in update-rc.d should actually let
"systemctl enable" start working again.

   --dkg

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), 
(200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages init-system-helpers depends on:
ii  perl-base  5.26.0-4

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
ii  insserv  1.14.0-5.4+b1

-- no debconf information
From 743df08123f386f8a04cad68121de83fc1d17c9d Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 4 Aug 2017 13:34:42 -0400
Subject: [PATCH] Support enabling default-disabled services.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Some services want to be shipped disabled by default (their
Default-Start is empty, and their Default-Stop is 0 1 2 3 4 5 6)

The systemd equivalent is a systemd service shipped with a vendor
preset "disabled" (see systemd.preset(5)).

In that case "update-rc.d foo defaults" should do the same as
"update-rc.d foo disable" (though https://bugs.debian.org/808887 notes
that "disable" fails in this case -- this patch fixes 808887 as well).

But "update-rc.d foo enable" for a service that is shipped disabled by
default ought to actually enable it.  This is the administrator
deciding that they're ready to enable the initially-disabled service.

This already works for runlevel 3 if the admin says "update-rc.d foo
enable 3".  But update-rc.d(8) says:

If no start runlevel is specified after the disable or enable
keywords, the script will attempt to modify links in all start
run‐ levels.

This patch assumes that the default runlevels (2, 3, 4, 5) are the
thing to enable if the administrator doesn't specify any runlevels
specifically, which matches widely held assumptions (e.g. in
/etc/init.d/skeleton).  I don't think it would make sense to enable in
'S' without the admin explicitly asking for it.
---
 script/update-rc.d | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/script/update-rc.d b/script/update-rc.d
index 6c8c0d0..c2a444c 100755
--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -393,7 +393,8 @@ sub sysv_toggle {
 ($start_lvls, $stop_lvls) = parse_def_start_stop($lsb_header);
 @toggle_lvls = @$start_lvls;
 if ($#toggle_lvls < 0) {
-error("$name Default-Start contains no runlevels, aborting.");
+warning("$name Default-Start contains no runlevels, using 2 3 4 
5.");
+@toggle_lvls = qw(2 3 4 5);
 }
 }
 
-- 
2.13.2