Re: Accpetance of Environment Variables in Attributes

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 25.06.20 22:04, Ede Wolf (listac@xxxxxxxxxxxxxxxx) wrote:

>
> > what exactly stands in your way to use
> > ExtecStart=/usr/local/bin/myscript.sh?
>
>
> Because my question was about making a template unit file more dynamic, not
> the process called by the unit.
>
> Having an environmentfile %i.env, that a) defines the environment for the
> actual service to be called (ExecStart=myservice --$OPTIONS...) but b) is
> also able to set different limits for that other instance of the same
> service.  Because a test webserver may be more restricted in
> resources.

I mentioned this before, but I think the addition of EnvironmentFile=
was a mistake I regret.

Conceptually it's just bogus, it's another layer of configurability,
that just complicates stuff.

Configure systemd settings in the systemd unit file, and configure the
service's own settings in the service's own configuration file. But
exporting both into yet another file is just bogus and broken and
makes things needlessly complex.

In sysv times people used /etc/sysconfig/xyz and /etc/default/xyz as
sourcable shell env blocks. It was result of the fact that init
scripts themselves were code, not declaration configuration. But in a
systemd world that has no value anymore, as unit files are declarative
configuration, and you should really just configure those.

This is particularly relevant as systemd knows drop-ins, knows
"systemctl edit", "systemctl revert" and "systemd-delta" and things
like that. If you move all the interesting settings one level out into
a separate env var file you break all that, make things even more
opaque and complex.

> This way I would only have to take care of _one_ external file to get
> another instance of service foo up and running. Copy the file,
> change the

No. You suddenly have to take of *one* *more* external file and break
all the usualy workflows with "systemctl edit", "systemctl revert",
"systemd-delta" and suchlike.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel