[systemd-devel] Variables in the [Unit] section of a server

Tom H tomh0665 at gmail.com
Thu Jan 14 11:37:33 PST 2016


On Thu, Jan 14, 2016 at 3:58 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Wed, 13.01.16 10:51, Steve Dickson (SteveD at redhat.com) wrote:
>>
>> Is is possible to set a variable in the [Unit]
>> section of a service?
>>
>> For example in rpc-gssd.service there is
>>     ConditionPathExists=/etc/krb5.keytab
>>
>> but for some installation the krb5.keytab
>> is in a different place. The rpc.gssd daemon
>> can be told this by setting a command line
>> argument from the EnvironmentFile.
>>
>> So people have to edit both the EnvironmentFile
>> and the rpc-gssd.service to make this change.
>>
>> So it would be nice if only the EnvironmentFile
>> need to be edit and the change would happen
>> in both places.
>>
>> Possible?
>
> Unit files are supposed to be configuration files, people can override
> and extend if they want to make changes. It's not recommended to use
> the EnvironmentFile= logic to externalise configuration. Instead, just
> keep the config in one place, in the unit files, to make things less
> opaque and more uniform.
>
> And no, unit files are not supposed to be a templating language and do
> not support generlized variable expansion and quite frankly I should
> never even have added the limited env var expansion via
> EnvironmentFile= that ExecStart= supports, since it invites people to
> externalise settings that way.

I understand that you'd prefer that we use drop-ins to set
"Environment=Foo=bar" or override "ExecStart=..." and it probably
works for most daemons - and should also be non-distro-specific.

But in the case of nfs, it would mean more messing around for admins
because there are many variables to set.

This is on Ubuntu 16.04 but RHEL and Fedora are similar because the
units are from upstream and distros simply have to modify
"/usr/lib/systemd/scripts/nfs-utils_env.sh":

root at localhost:/lib/systemd/system# grep Start= nfs-* rpc-*
nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS
nfs-config.service:ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh
nfs-idmapd.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
nfs-kernel-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
nfs-utils.service:ExecStart=/bin/true
rpc-gssd.service:ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
rpc-statd-notify.service:ExecStart=-/sbin/sm-notify $SMNOTIFYARGS
rpc-statd.service:ExecStart=/sbin/rpc.statd --no-notify $STATDARGS
rpc-svcgssd.service:ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS

root at localhost:/lib/systemd/system# grep Env nfs-* rpc-*
nfs-idmapd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-kernel-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-mountd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-gssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-statd-notify.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-statd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-svcgssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils

root at localhost:/lib/systemd/system#

nfs-config.service runs "/usr/lib/systemd/scripts/nfs-utils_env.sh",
which sources "/etc/default/nfs-{common,kernel-server}"
("/etc/sysconfig/nfs" on RHEL and Fedora) and generates
"/run/sysconfig/nfs-utils". Setting the variables unit-by-unit would
be a PitA.


More information about the systemd-devel mailing list