[systemd-devel] Environment & EnvironmentFile in unit files

[Gustavo Sverzut Barbieri]

On Thu, Jan 27, 2011 at 8:10 AM, Lucian Muresan
<lucianm at users.sourceforge.net> wrote:
> 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?

I'll let  the final decision to Lennart and Kay, the maintainers, but
from what I see and agree the idea is to avoid such crap completely.

1. these ExecPreStart are completely non-sense. These should be in
lircd if it really needs it. Send them the patches to fix it.
Meanwhile just make this a single binary that does such work, but
consider it a temporary remedy.

2. these non-daemon configuration files should be removed. It causes
no good other than stupid fragmentation among distributions (some in
/etc/conf.d, others in /etc/sysconfig, ...). The way to go is the
daemon itself to have its configuration file and read it directly.

3. do not use forking. I consider it a temporary solution, but the way
to go is to make the daemons do not fork and let systemd babysit them.
If lircd does not support something like that, send them the patches.

4. last but not least these things that rely on /dev should be
activated by udev whenever it notifies the device is presence.


> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202