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.
Agreed.
> 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?
--
Saludos,
Felipe Sateler
Reply to: