Thanks again for your in depth reply.
> it's a very different kind of language, as these specifiers are
> defined by systemd itself
Maybe someday someone will find a safe way to inject addtionally,
arbitrary values into systemd. There are still some free letters left
that can be prefixed
On Do, 25.06.20 22:04, Ede Wolf (lis...@nebelschwaden.de) 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
On Do, 25.06.20 20:25, Ede Wolf (lis...@nebelschwaden.de) wrote:
> Does work, so %i works, $SOMETHING not. Different naming, different way of
> invocation, I am aware of that, but in general it still the usage of
> variables. And the likes of %H, %m or %v are some form of environment,
> aren't
On Fri, Jun 26, 2020 at 3:39 AM Ede Wolf wrote:
>
> > I do this today using a drop-in, because environment variables can be
> > set there as well. It works very well, exactly as you describe. There
> > is a template service unit file, and a drop-in directory for each
> > instance which contains a
I do this today using a drop-in, because environment variables can be
set there as well. It works very well, exactly as you describe. There
is a template service unit file, and a drop-in directory for each
instance which contains a file that sets the environment variables and
also provides values
On Thu, Jun 25, 2020 at 4:04 PM Ede Wolf wrote:
> 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 few options for the unit as well as for the service in ONE place,
> startup the template. Ultra
> > If you want a shell, use a shell.
> Given the dominance of systemd, this is only in parts realistic.
A shell, or even an entire program in a language of your choice, can determine
the parameters by some logic then invoke systemd-run. Voilà, you get as much
flexibility as you want plus all
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
Am 25.06.20 um 20:25 schrieb Ede Wolf:
> Am 25.06.20 um 14:30 schrieb Lennart Poettering:
>> Nah, unless you write a shell or templating language I doubt variable
>> expansion is a good thing.
>
> I am aware, that discussion here is futile, but this is contradictious,
> because:
>
> [Unit]
>
Thanks for the heads up, but I've just used nobody as an example here,
because everybody knows, it is a systems user and therefore not to be
confused. Just to make it more clear.
Generally I do like the concept of dynamic users, but there are still
some open questions left and therefore needs
Am 25.06.20 um 14:30 schrieb Lennart Poettering:
Nah, unless you write a shell or templating language I doubt variable
expansion is a good thing.
I am aware, that discussion here is futile, but this is contradictious,
because:
[Unit]
Description=test service
[Service]
User=%i
Type=oneshot
> [Service]
> User=nobody
May I interject that DynamicUser=yes is generally superior to User=nobody.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Do, 25.06.20 14:07, Ede Wolf (lis...@nebelschwaden.de) wrote:
>
> > I am not sure what made you think this works, but systemd has no
>
> Pure logic of conclusion. Besides this being a sensible thing to be
> able to
Nah, unless you write a shell or templating language I doubt variable
I am not sure what made you think this works, but systemd has no
Pure logic of conclusion. Besides this being a sensible thing to be able
to do, why is LimitMEMLOCK not causing the unit to fail, when given a
(non existing) variable? Or, since it is no variable from a systemd
point of
On Do, 25.06.20 13:24, Ede Wolf (lis...@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
Normally you'd set instance-specific variables using an override file
for the unit. You could easily put just 'User' and 'LimitMEMLOCK' in
the override file and leave the rest of the service settings in the
main unit file, with no need for an environment variable file at all.
On Thu, Jun 25, 2020
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
This service failes to startup, as I cannot seem to being able to use a
variable for the
17 matches
Mail list logo
