[systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

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

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

-- 
Lennart Poettering, Red Hat