On Di, 26.09.17 21:07, Matthew Giassa ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
