[systemd-devel] Query regarding "EnvironmentFile"

[Soumya Koduri]

On 12/10/2015 01:16 AM, Lennart Poettering wrote:
> 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}
>> ........
>> .......
>>
>>
>>
>> My intention is to execute/start nfs-ganesha-config.service always prior to
>> running nfs-ganesha.service (even during restart).
>>
>> nfs-ganesha-config.service writes certain configuration values to
>> '/run/sysconfig/ganesha' which I would want nfs-ganesha.service to read
>> before starting ganesha.nfsd daemon.
>>
>> But from my tests I see that nfs-ganesha.service picks up old configuration
>> values defined in '/run/sysconfig/ganesha' than the ones generated by
>> 'nfs-ganesha-config.service' at that point. So I am assuming
>> 'EnvironmentFile' gets loaded prior to running any dependent services (which
>> is 'nfs-ganesha-config.service' here).
>>
>> Please confirm if that is the case. Also is there any way to load
>> 'EnvironmentFile' only after executing all the dependent services.
>
> EnvironmentFile= is processed immediately before forking off the
> service process. The env vars the process will see are hence the
> contents of that file after all deps with After= ran.
>
> (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.)
>
Thanks again for the clarification and your inputs. I wanted to 
understand the behavior before taking any other approach.

-Soumya

> 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.
>
> Lennart
>