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

[Bob Proulx]

Thorsten Glaser wrote:
> Bob Proulx wrote:
> >     root at angst:/etc# find /etc/rc?.d -name '*bind9' -delete
> >     root at angst:/etc# find /etc/rc?.d -name '*bind9'
> > 
> > All removed.  The re-install will reset the links to the defaults.
> > 
> >     root at angst:/etc# apt-get install --reinstall bind9
> [...]
> >     root at angst:/etc# find /etc/rc?.d -name '*bind9'
> >     /etc/rc0.d/K04bind9
> >     /etc/rc1.d/K04bind9
> >     /etc/rc2.d/S03bind9
> >     /etc/rc3.d/S03bind9
> >     /etc/rc4.d/S03bind9
> >     /etc/rc5.d/S03bind9
> >     /etc/rc6.d/K04bind9
> 
> Yes, and that MUST NOT happen.

I disagree.  I believe this must happen.  Other possibilities are worse.

> > Removing the S* links instead of disabling them with a K* link.  But
> > leaving the K* links so it is an installed configuration.  Then
> 
> If the local administrator actively disables an init script, e.g. by
> update-rc.d remove, it MUST NOT be re-added later. (This MIGHT require
> insserv and update-rc.d to coordinate on "manually removed" state, but
> this state MUST NOT be the presence of ANY symlinks for that script.)

Some time ago someone made an argument similar to this for conffiles.
That if a conffile were removed that it was an intentional change.
Even if accidental.  And then things were changed so that if a
conffile is removed then that is now considered a local change.  And
that broke a lot of things!  And then DPkg::Options::=--force-confmiss
was needed to fix the introduced breakage.  Required because the
alternative of purging a package and installing fresh to get back a
conffile that had been accidentally deleted was problematic for many
reasons.  And now EVERY TIME I upgrade I MUST ADD --force-confmiss TO
THE COMMAND or it is possible I will not get a correct installation.
And this is a change that hurts the less informed the most.

Whatever results from this discussion please let's not make the cure
worse than the problem!  At a technical level having no configuration
looks identical to not (yet) having installed anything.  Therefore it
makes the most sense that if there is no configuration that when a
package is installed or upgraded that one should be installed and
configured.  That's the principle of least surprise.  Anything else
would require that notice be placed on display in the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign saying
"Beware of the Leopard." and would be a worse problem for the typical
use case.

> Disabling an init script is *not* the same as leaving a K link...
> because a K link will attempt to stop the service if manually started.
> This MUST NOT happen.

Runlevel 6 is the reboot level and all init scripts there are K links.
Before introducing extraordinary breakage I think it should require
extraordinary proof for saying why leaving a K link in runlevel 6 is
so very bad that it is a MUST NOT happen?  Why?  Because I am unable
to think of any case when having a single K link in runlevel 6 is
incompatible with a desire for the init system to get out of the way
of local changes.

> Considering raising severity on this as disabling with update-rc.d remove
> does not work and disabling with update-rc.d disable wrongly leaves any K
> links around which causes unrelated software, that is, a manually started
> service, to be broken, that is, stopped.
> 
> I just had this happen, so it isn't an academic mind exercise.

The reverse is also true.  The opposite behavior of not installing
symlinks if there is no configuration will absolutely break my use of
it, and many others.  And it will change behavior that has been in
place for many years.  And in similarity to your claim I will mirror
it myself and say that it also must not happen.

Cheers! :-)
Bob