Re: Steps towards a patch to document disabling a daemon upon installation

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sean Whitton writes ("Steps towards a patch to document disabling a daemon upon installation"):
...
> [draft policy text]
...
> > +The default behaviour is to enable autostarting your package's daemon.
> > +If the daemon should not be autostarted unless the local administrator
> > +has explicitly requested this, use instead add to your ``postinst``
> > +script
> > +
> > +::
> > +
> > +    update-rc.d package defaults
> > +    update-rc.d package disable

This has a bug: after the first rune, but before this second, starting
the daemon is enabled.  (This is a regression compared to the previous
approach.)

To make this work correctly, I think we need a new update-rc.d
mechanism which provides, in one go, the equivalent of
  update-rc.d DAEMON defaults && update-rc.d DAEMON disable

Something like
  update-rc.d DAEMON add-disabled
maybe.

> > +An older practice, which should not be used, was to include a line
> > +like ``DISABLED=yes`` in the package's ``/etc/default`` file.  The
> > +package's init script would not start the service until the local
> > +system administrator changed this to ``DISABLED=no``, or similar.
...
> 1. Is the 'should not' for the /etc/default practice too strong?  I
>    don't know an efficient way to find out how many packages this would
>    make buggy.  But given that we have very strong reasons against the
>    old practice, we might want to use a 'should not' regardless.

On sysvinit systems, using update-rc.d disable/defaults are rather
more awkward:

 * Enabling and disabling cannot, in practice, be conveniently made
   without using the update-rc.d tool.

 * Enabling and disabling generates a tremendous amount of noise in
   /etc (especially visible when using etckeeper).

> 2. Do we need to include any text saying *why* the /etc/default practice
>    is a bad idea?  I couldn't come up with a succinct way to state it.
>    In general, I think we can err on the side of not including the text,
>    since we have policy bugs that document the reasons.

How about this text:

  Setting a value in /etc/default/PACKAGE is nowadays troublesome
  because supporting that pattern is very hard due to inflexibility in
  systemd, which is usually the default init system.

This also makes it clear that this pattern is perfectly fine if for
any reason the package does not support systemd.

> 3. The maintscript snippet I have added is not right because it will
>    disable the daemon every time the package is updated.  Unfortunately,
>    the postinst doesn't know whether this is a new installation, or an
>    upgrade.

This should also be fixed with a new update-rc.d rune.

>    I looked at dh_installinit(8) and update-rc.d(8) and I couldn't get
>    them to generate a postinst that does what I want.  It seems you're
>    expected to use all three of these:
> 
>        dh_systemd_enable --no-enable
>        dh_systemd_start --no-start
>        dh_installinit --no-start
> 
>    but then after a reboot, a sysvinit system will start the daemon,
>    AFAICT.

I can't speak to the behaviour of systemd, but I think the

  update-rc.d add-disabled

operation I propose would, for sysvinit systems, do the follow:

1. Are there already rc*.d links for DAEMON ?  If so, do nothing.

2. If not, create them in the way that  defaults && disable
  would have done.

Ian.