Bug#975591: update-rc.d disable

Tom H tomh0665 at gmail.com
Mon Dec 21 06:58:14 GMT 2020


On Sun, Dec 20, 2020 at 11:44 PM Thorsten Glaser
<t.glaser at tarent.de> wrote:
> On Sun, 20 Dec 2020, Tom H wrote:


>>> There *absolutely* HAS to be some way to disable an init script
>
>> It depends what's meant by "disable".
>
> Which part of “disable an init script” did you not understand?

Perhaps all of it :)


>> If it means "disable <daemon> from starting at boot", then
>
> No.
>
>> If it means "disable <daemon> from starting at all", then
> "update-rc.d
>
> No.
>
> 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".


>> It feels like a lot of work for an unusual corner case.
>
> It’s by no means an unusual corner case.
>
> Installing a package to have a dæmon binary (or really any
> file from it) available but not intending for the initscript
> to run isn’t anything special. There’s even standardised-ish
> ways to do so (chmod -x the dæmon binary), which however
> won’t be usable if users need to start it manually.

The current "update-rc.d <daemon> disable" does achieve this.

But you want to disable an init script, start it manually, change
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
"update-rc.d <daemon> disable" has to mean, by default, disable
"<daemon>" in runlevels 2-5. So, if you start "<daemon>" manually and
change runlevels, it'd be a bug if it weren't stopped.

If you know in which runlevel "<daemon>" shouldn't be stopped (let's
assume "3"), you can run "update-rc.d <daemon> disable 245" or
"update-rc.d <daemon> disable 2 4 5" or run three separate invocations
(the syntax's unclear to me).

So the current API does provide you with an imperfect but usable
method. Like Bob P, I'd rather not have to deal with the unintended
consequences of a change in API (of "remove" or "disable").


> (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.



More information about the Debian-init-diversity mailing list