On 12/21/2015 04:36 PM, Michael Biebl wrote:
2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson <[email protected]>:
It's an added work to add the environmental line to begin with and it's an
That would be done once, by upstream ideally. The work would be negligible.
Still an added work either upstream/downstream + these still have to be
maintained/updated which people often neglect to take into consideration.
equal amount of work for administrators to change the environmental line or
the Exec= line(s) so the benefit is none
That is not true when considering upgrades.
You are right but for that particular feature of systemd it's a question
for distribution/upstream whether it should not that it can.
Transparently updating type unit files on update/upgrades can break
running system/setups ( especially when it comes down to the security
options that systemd provides being added to those type unit files,
people have a hard time getting those right in general let alone taking
into considerations all the variants of setups out in the wild ) just
like upstream changes in configuration files for a set of
daemon/services ( httpd 2.2 vs 2.4 for example ).
Administrators on these parts want to have full control over their
systems since each downtime can cost significant amount of money for
their company or clients of their company so this feature is not even
considered a feature while hobby administrators, devops and plain end
users might consider this a feature since downtime is irrelevant or less
important to them and does not cost them money or even their job if it
happens.
Bottom line some people look at what you pointed out as con for using
environment to handle daemons startup options not as a feature while
others might.
With environmental files administrators will have to keep tabs on two files
I specifically didn't talk about EnvironmentFile=, but Environment=
Right I was just pointing out that if the intent is to support multiple
init system then you must use EnvironmentFile=not Environment= to
achieve that goal.
JBG
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
