Am Thu, 10 Dec 2015 01:08:34 +0100 schrieb Reindl Harald <[email protected]>:
> 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 [email protected] 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. --
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
