[systemd-devel] Environment & EnvironmentFile in unit files

Lucian Muresan lucianm at users.sourceforge.net
Thu Jan 27 02:10:51 PST 2011


Hi there,

I'm in the process of migrating my HTPC setup running Gentoo to using
systemd for faster booting, and so far I'm almost up and running and
enjoying systemd, I would like to thank you for this software.

However, I had my difficulties, and one of them is with environment
variables in unit files. Are they really solely meant to be used for the
started processes, and in no other unit file directives? I'd like to
give some examples, where I could have used them in order to reduce
redundancy in the unit files code and also give the user configuration
opportunities via "EnvironmentFile=" for more than the command line for
launching the process itself, without having him to modify the unit
file. You might point out conceptual errors I'm doing, but hopefully I
can clarify what my problem is, maybe you'll consider this as a feature?

1. example: LIRC daemon:

cat /etc/systemd/system/lircd.service:
[Unit]
Description=LIRC Daemon
After=network.target
Name=lirc

[Service]
Type=forking
EnvironmentFile=/etc/conf.d/lircd
PIDFile=/var/run/lirc/lircd.pid
ExecStartPre=/bin/mkdir -p /var/run/lirc
ExecStartPre=/bin/rm -f /dev/lirc
ExecStartPre=/bin/rm -f /var/run/lirc/lircd
ExecStartPre=/bin/ln -s /var/run/lirc/lircd /dev/lirc
ExecStart=/usr/sbin/lircd -P /var/run/lirc/lircd.pid $LIRCD_OPTS
ExecStopPost=/bin/rm -f /dev/lirc
ExecStopPost=/bin/rm -fR /var/run/lirc

[Install]
WantedBy=multi-user.target


cat /etc/conf.d/lircd:
# Options to pass to the lircd process

# for devices with lirc-kernel-module
#LIRCD_OPTS="-d /dev/lirc0"
#LIRCD_OPTS="-H atilibusb -o /var/run/lirc/lircd"

# for devices using the input-layer
LIRCD_OPTS="-H devinput -d /dev/input/x10-remote"
#LIRCD_OPTS="-H name='*X10 WTI RF receiver*'"



As you can see, there are several places where common paths are used,
not only in ExecStart= but also in ExecStartPre= and PIDFile=, so being
able to use environment variables in this places would reduce redundancy..



2. example: LIRC's irexec daemon:

cat /etc/systemd/system/irexec.service:
[Unit]
Description=LIRC irexec Daemon
Requires=lircd.service
After=lircd.service

[Service]
Type=forking
EnvironmentFile=/etc/conf.d/irexec
User=vdr
ExecStart=/usr/bin/irexec --daemon $IREXEC_OPTS

[Install]
WantedBy=multi-user.target


cat /etc/conf.d/irexec:
# Options to pass to the irexec process
IREXEC_OPTS="/etc/lircrc"

# User to execute irexec as.
# Warning: Running irexec as root can open security holes
#IREXEC_USER="root"
IREXEC_USER="vdr"


For this one, it's really a pity that the user under which the process
should be executed cannot be read from the external environment file...


3. example: I have several automount + mount units for remote
filesystems like this:

cat /etc/systemd/system/mnt-remote-GenLSPro_share.mount:

[Unit]
Description=GenLSPro share
DefaultDependencies=no
Requires=rpcbind.target
After=rpcbind.target

[Mount]
What=GenLSPro:/mnt/share
Where=/mnt/remote/GenLSPro_share
Type=nfs
Options=rsize=1024,wsize=1024,timeo=14,intr,hard,nfsvers=3,proto=udp

Here I could really use the possibility to pass the mount options to the
"Options=" directive from a common external file where I set all options
for different file types, something like MOUNT_OPTS_NFS3,
MOUNT_OPTS_CIF, MOUNT_OPTS_NFS4, etc.


Best regards,
Lucian


More information about the systemd-devel mailing list