[systemd-devel] Query regarding "EnvironmentFile"

[Kai Krakow]

Am Thu, 10 Dec 2015 01:08:34 +0100
schrieb Reindl Harald <h.reindl at thelounge.net>:

> Am 09.12.2015 um 20:46 schrieb Lennart Poettering:
> > I probably should never have added EnvironmentFile= in the first
> > place. Packagers misunderstand that unit files are subject to admin
> > configuration and should be treated as such, and that spliting out
> > configuration of unit files into separate EnvironmentFiles= is a
> > really non-sensical game of unnecessary indirection
> 
> i strongly disagree

I disagree, too, about "should never have added". But I totally agree
with the point that packagers misunderstood the purpose of those files.
And this whole discussion perfectly shows it.

> it's the easiest way to not touch/copy the systemd-unit *and* 
> systemd-snippets for just adjust a simple variable - the point here
> is simple
> 
> copy units and/or add own snippets has easily two side effects
> 
> * don't get well deserved updates for the units
> * or snippets don't play well with later dist-versions of the unit
> 
> a EnvironmentFile supported by the distributions unit is well better
> for simple adoptions

An environment file should never be used to configure the runtime
behavior of a service [1], e.g. trigger conditionals in config files in
a way that they are not propagated during a service reload.

Instead, they are very useful in service instantiation by using the
servicename at .service templating pattern. E.g. for nspawn services you
could create different configuration options that apply for container
boots but not during runtime. Or you could create different instances
of MySQL. Or, or, ... I'm sure you get the point. For me this is almost
the only valid point in using such files.

All other purposes are ugly remnants of sysvinit workarounds to cope
with completely unmaintainable and complex scripts.

So, environment variables should go into service overrides or
directly into config files which you edit instead of creating new config
files. If you apply your own config management, then well, go with an
environment file if you feel so. I think it's okay. But this should
never ever be shipped as a default distribution configuration (but it
could be valid as an example, with proper documentation of the
side-effects this can have). You still should or want to modify your
exec line because:

The problem with a purpose of not modifying the exec line is that
vanishing options may be silently ignored during upgrades while after
an upgrade the service may instead fail if you added a now
incompatible/deprecated option. And that is a good thing [tm]. The
latter way makes debugging upgrade problems a lot easier and makes
better upgrade paths. If you totally feel like not putting your
production server into problems (and you really should), you have a
staging server anyways where you apply updates first, then fix things,
then apply the upgraded configuration management to the farm along with
the package updates. Virtualization and/or containers make that easy
and cheap.

Concluding: The option should stay but please package maintainers
remove your ugly cruft. This is something I constantly struggle with
the way it is done in Gentoo for elasticsearch. But actually it's
encouraged that way by the developers probably - and that's now the
outcome of this pita.

Thus: Please maintainers and developers, remove it. Do not let Lennart
remove this useful option to force others into removing your shitty
cruft. A service file should always do the correct thing upon invoking
either reload or restart respectively. Let the admin break this rule if
she or he feels like doing so. But do not ship that broken behavior as
a default.

Regarding the OP and a few follow ups a German saying comes to my mind:
"Das kannst'e zwar so machen, is' aber scheiße" :-) So let's better
support him into fixing his configuration and doing it the proper way
instead of insisting who is right or who is wrong. The concept of
environments files is clearly misused in many cases. Nothing is really
bad about it.

[1]: Unless you know what you're doing - but as stated it should not
come by default and thus offer a way to easily screw your system.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20151221/8a7229fa/attachment.sig>