Bug#975591: update-rc.d disable

[Tom H]

On Mon, Dec 21, 2020 at 8:11 AM Thorsten Glaser <t.glaser at tarent.de> wrote:
> On Mon, 21 Dec 2020, Tom H wrote:


>>> It means “do not call this init script in any runlevel”,
>>> which *ought* to be very obvious.
>>
>> "do not call this init script in any runlevel" can be understood
>> as "kill it in any runlevel".
>
> No, absolutely not, NO, NO, *NO*. *GAH!*

That's how it's been designed and implemented.

FTR, "update-rc.d <daemon> disable" was introduced 10 years ago, in
Squeeze, and this is the first time, unless there's another similar
bug, that the definition of "disable" has caused a problem.


>> But you want to disable an init script, start it manually, change
>
> (or start the daemon manually without that init script)

That's irrelevant:

# pgrep named
1057

# service named stop
Stopping domain name service...: namedwaiting for pid 1057 to die
.

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

# pgrep named

# named -u bind

# pgrep named
1255

# telinit 3

# pgrep named
1255

#


>> runlevels, and expect it to keep on running. I consider that a
>> corner case because, by default on Debian, runlevels 2-5 are the
>> same, so
>
> They are not, they are just configured identically.

Semantics.


> Also, don’t deviate from the point in question with irrelevent
> details. If you must, imaging some kind of dæmon that handles,
> oh, say a fuse filesystem.

I'm not deviating. You brought up the runlevel change as an example of
where "disable" fails in your view.


>> method. Like Bob P, I'd rather not have to deal with the
>> unintended consequences of a change in API (of "remove" or
>> "disable").
>
> Looking at their descriptions, I agree. But a new facility
> to achieve this is definitely needed.
>>>
>>> (Curiously wondering whether systemd handles _this_ right…)
>>
>> If you disable a service, it can be started manually or as a
>> dependency of of another service.
>>
>> If you mask a service, it cannot be started at all.
>
> Not even by calling /usr/sbin/${foo}d?

No. If a service is masked, you can't start it via "systemctl", but
you can call it directly.


> The problem here is that these are terminated by the initscript,
> even if that was not used to start them.

No. See "named" above.