Re: Bug#601455: Steps towards a patch to document disabling a daemon upon installation
Hi,
On Mon, Dec 25, 2017 at 06:27:21PM -0800, Russ Allbery wrote:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > Sean Whitton writes:
>
> >> 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.
I don't find anything about the above text to be true.
>
> > This also makes it clear that this pattern is perfectly fine if for
> > any reason the package does not support systemd.
>
> I don't really agree with this -- I've disliked this approach (and there
> were debian-devel threads against it) from long before systemd was
> written. The explanation I'd give is that:
While I have several other things I find bad about the /etc/default/foo
anti-pattern I think the below text is short and clear that it should
serve well as one warning against it, thus...
>
> Setting a flag in /etc/default/PACKAGE hides from the init system
> whether or not the daemon should actually be started, which leads to
> inconsistent and confusing behavior: ``service <package> start`` may
> return success but not start the service, services with a dependency
> on this service will be started even though the service isn't running,
> and init system status commands may incorrectly claim that the service
> was started.
Seconded.
Regards,
Andreas Henriksson
Reply to: