[systemd-devel] Antw: [EXT] Re: Accpetance of Environment Variables in Attributes

[Lennart Poettering]

On Fr, 26.06.20 11:40, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> > I am not sure what made you think this works, but systemd has no
> > concept of env var expansion in unit files. It's not a shell.
>
> But is there actually a good reason not to allow it?

We don't want to be a language interpretor for an iterative or
template language. There are enough of those. And you can easily plug
m4 or whatever you want before systemd. systemd's unit files are
supposed to be purely declarative. The model is indeed weakened by
specifiers and by the env var expansion in ExecStart= and friends, but
the language itself is still declarative.

> > There's one exception: in ExecXYZ= settings there's env var expansion,
> > but that's really it. And it's expanded at the moment of execution,
> > i.e. not part of the unit file language, but of the executor code.
>
> In the version of the man pages I have the decription of ExecReload= in
> systemd.service(5) says "Specifier and environment variable substitution is
> supported here following the same scheme as for ExecStart=.", but the word
> "environment" doe not occur in the description of ExecStart. ;-)

There's a whole section in the man page about this, it's called
"Command Lines". It's referred to in the first line of the explanation
of ExecStart=.

> Maybe there should the a special syntax to access environment variables on any
> right side. Maybe the problem is that the environment settings may change
> during lifetime of a service. Not so much in the service itself, but for the
> systemd commands started later. If they re-evaluate the environment each time,
> thing might change.
> A possible solution could be a copy of any environment variable being used.
> Unclear is _when_ the copy should take place however.

Just use m4 or shell. No need to duplicate in systemd what those
languages already do.

Lennart

--
Lennart Poettering, Berlin