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

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 25.06.2020 um 13:33
in
Nachricht
<25312_1593084828_5EF48B9C_25312_52_1_20200625113339.GA160936 at gardel-login>:
> On Do, 25.06.20 13:24, Ede Wolf (listac at nebelschwaden.de) wrote:
> 
>> So I have an environmentfile containing two variable definitions:
>>
>> RUNASUSER=nobody
>> MEM=4294967296
>>
>> And my service section reads:
>>
>> [Service]
>> EnvironmentFile=/path/myfile
>> User=$RUNASUSER
>> LimitMEMLOCK=$MEM
> 
> 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?

> 
> 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. ;-)

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.

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel