Bug#975591: insserv/update-rc.d coordination missing (was Re: Canonical method to locally disable an init script?)

Thorsten Glaser t.glaser at tarent.de
Mon Dec 14 17:12:48 GMT 2020

# I am almost considering RC severity here
severity 975591 important
retitle 975591 insserv: no way to fully disable an init script

On Mon, 14 Dec 2020, Lorenzo wrote:

> with update-rc.d remove you are not disabling the service, you are
> purging it while it's still installed.

Okay, I can accept that…

> The only way supported in update-rc.d to disable a service is
> update-rc.d disable

… but not this.

“update-rc.d disable” does *NOT* disable a service. Instead, it
sets it to “stopped in all runlevels”, which is evidently *not*
the same.

I don’t care if “update-rc.d disable” gets changed or a new API
gets added, but this has to be fixed.

There *absolutely* HAS to be some way to disable an init script
completely *without* insserv automatically re-enabling it on the
next package upgrade/install.

As it was said that insserv uses the existence of the symlinks as
its only state, regarding this at least, it’s crystal clear that
at the very least something has to change in insserv.

Depending on which interface (“disable” or something new) is
chosen, update-rc.d from init-system-helpers must also change.

> This is interesting: could you please write the exact sequence that
> cause a manually started service to be stopped when there is a K
> link in the current runlevel?

Eh, trivial:

• start the service
• switch the runlevel

> I suspect what you want is a new feature in update-rc.d, but it
> depends on your answer to my question above.

Apparently this must be supportable by insserv first: Bob said…

| In order for local changes to persist at least one symlink must be
| present so that the installation tools know that this is previously
| exist and that they should not install the default.

So first insserv must be extended to support fully disabling init
scripts then update-rc.d must be extended/changed to call this.

While this may indeed be considered a “new feature” it is critical
to proper system operation.

tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.


More information about the Debian-init-diversity mailing list