[systemd-devel] Question: path-based deactivation or equivalent

[Lennart Poettering]

On Di, 26.09.17 21:07, Matthew Giassa (matthew at giassa.net) wrote:

> Additionally, does systemd support assigning an environment variable to an internal variable, ie:
> 
> Environment=MYPIDFILE=/var/run/mine.pid
> PIDFILE=$MYPIDFILE

systemd unit files are not supposed to be a templating engine. If you
want one use m4 or such.

Environment= configures the environment for the executed process,
that's all really.

> I know there are workarounds for ExecStart for example, using
> /bin/bash to evaluate environment variables, but I think that
> special case only applies to ExecStart, ExecStartPre, and Executor,
> as they actually get executed rather than just assigned, allowing
> for some degree of variable expansion.

Yes, ExecXYZ= do some basic variable expansion, and I regret these
days that I added that, it makes unit files a bit too magic, they are
supposed to be simply key-value files...

Note that the set of environment variables passed to executed
processes is the combination of a number of sources: the stuff from
Environment=, the stuff from EnvironmentFiles=, the system-wide
Environment=, the stuff pulled in via PassEnvironment=, the stuff set
via PAM modules (if PAMName= is used) as well as what systemd sets on
its own (MAINPID=, LISTEN_FDS=, NOTIFY_SOCKET= and such). Many of
these fields are only known at the moment of activation (for example,
MAINPID= is set to the main PID of a service, but that's only known if
we actually started that already), and hence we can't expand env vars
in other statements even if we wanted: loading configuration files
happens much much earlier than activation after all. Only in ExecXYZ=
we can do the minimal expansion we do, as right when we fork off the
process we actually know the environment we'll pass too.

Lennart

-- 
Lennart Poettering, Red Hat