Bug#975591: update-rc.d disable

[Lorenzo]

On Mon, 21 Dec 2020 13:19:59 -0400
Jesse Smith <jessefrgsmith at yahoo.ca> wrote:

> As I understand it Thorsten is looking for a way to have a service
> installed, that can be run or stopped manually. But the service is
> never started/stopped automatically when switching runlevels. Is that
> correct?

I think he might have issues also with start/restart/stop during
package upgrades, but i'm not sure..

> 
> If it is, I wonder if insserv's "overrides" feature would work here?
> An override is a file which sets which runlevels will be used to
> start/stop a service that is kept in a separate location so as to not
> be overwritten by the package manager. If the override file was
> created and set so it had no start/stop runlevels then I think the
> service would only start/stop when manually controlled (ie with
> /etc/init.d/service-name stop).
> 
> There is a short write-up on insserv overrides in its manual page.
> Would that suit the purposes here? If so, then I think we don't need
> to extend insserv, jut add a feature to update-rc.d which would
> create a minimal overrides file for given service. Thoughts?
> 
> Jesse
> 

It will probably works but I suggest a more radical approach:
if the sysadmin doesn't want insserv to manage the symlinks, then just
don't call insserv seems the right thing to do.

I suggest something like the following

* Add a new command 

update-rc.d mask/unmask

The default state is unmask: when a service is masked the sysadmin is
supposed to take care of symlinks in all runlevels, and also he decides
when to start/stop/restart the service

* use a flag file to mark a service as masked

for example, a 'foo' service is considered masked if
/etc/init.d/.foo file exists

* update-rc.d defaults/defaults-disabled are noop when a service is
  masked (so insserv is not called during install/upgrades..)

* update-rc.d remove will remove the flag file, if any (it's called only
  on purge)

* all invoke-rc.d actions are noop when a service is masked


This way the sysadmin will be able to delete the symlinks (or set an
arbitrary boot order) without having to deal with insserv reordering
the links.  It also ensures that the service does not get
started/stopped automatically with package upgrades.

Thorsten, could you please clarify which approach you think will better
suits your needs?

Lorenzo