[systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B. Guðmundsson]

On 12/18/2015 04:00 PM, Michael Biebl wrote:
> 2015-12-09 20:46 GMT+01:00 Lennart Poettering <lennart at poettering.net>:
>> On Wed, 09.12.15 18:27, Soumya Koduri (skoduri at redhat.com) wrote:
>>
>>> Hi,
>>>
>>> I have created a systemd.unit(nfs-ganesha.service) file as below :
>>>
>>> [Unit]
>>>
>>> After=nfs-ganesha-config.service
>>> Requires=nfs-ganesha-config.service
>>> ....
>>>
>>> [Service]
>>> EnvironmentFile=-/run/sysconfig/ganesha
>>> ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
>> (But honestly, there's really no point in trying to dynamically
>> convert stuff into a file that is suitable for EnvironmentFile=. I
>> mean, if you want a shell script, then use a shell script, and invoke
>> that from the main daemon's ExecStart= line, and make it exec the real
>> daemon as last step. There's really no point in playing these
>> multi-service conversion games. Also /etc/sysconfig is a Redhatism
>> that should really go away, the whole concept is flawed. Adding a new
>> /run/sysconfig/ certainly makes that even worse.)
>>
>> 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 do think that overriding the complete ExecStart= line is usually
> suboptimal and not what you want if you just want to pass additional
> options to the daemon.
>
> Maybe a good middle ground / recommendation for such daemons would be,
> to ship a line
>
> ExecStart=/usr/sbin/foobard $OPTS
>
> and then tell admin to use systemctl edit
> [Unit]
> Environment=OPTS=-baz
>
> bonus points if we could standardise the $OPTS var name across daemons.
>
> Then distros like Fedora could do a one-time migration of their
> settings in /etc/sysconfig/foobar and drop the file after the upgrade.

This makes no sense.

Here you are just adding an extra line with no value on top of requiring 
some form of standardize the $OPTS var name across daemons ( as opposed 
to administrators simply change the value of the line directly ).

Best practice and the least amount of work for administrator ( both in 
editing and for other administrators to keep taps on changes made by 
others ) is to copy/edit the entire unit.

Lennart can better explain what value he saw in introducing those 
snippets compared to that since he introduced them in the first place.

JBG