On Mon, Dec 21, 2020 at 8:11 AM Thorsten Glaser <t.gla...@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.
