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