Web lists-archives.com

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

On Mon, 11 Sep 2017 14:41:12 +0100, Ian Jackson wrote:

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

FWIW, there's a bug for that: #857452

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

The /etc/default/PACKAGE thing was an anti-pattern before systemd 
appeared, so gratuitous jabs at it are out of place. I suggest instead 
mentioning the real reasons its bad:

1. Two interfaces for disabling services, which is confusing. All init 
systems already have an interface to disable services, so it is better to 
use that instead.
2. Nonstandard interface: is the knob called DISABLE or ENABLE? Is it 
ENABLE_FOO or ENABLE_BAR? Or maybe BAR_ENABLED? Since the pattern is 
reinvented by different services there is inconsistency.
3. Confusing and incorrect bootup messages. "Foo doesn't work even though 
I see that it starts at boot!"
4. Inability to start disabled services. A service with ENABLE=no can't 
be started without editing the default file, and then you have to 
remember to set it back before reboot.

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

Currently, update-rc.d leaves all the hard work to insserv under sysvinit. 
The behaviour would have to change to check if any links exist and skip 
invoking insserv in that case. I am not sure if that would mean a behavior 
change though. Maybe this early in the release cycle is a good time to 
try these kinds of changes.

For systemd, this operation would be a nop. I don't know about other init 
systems. What would they need?

Felipe Sateler