[systemd-devel] Option substitution in unit configuration files?

[Lennart Poettering]

On Sun, 16.08.15 16:36, Malte Forkel (malte.forkel at berlin.de) wrote:

> Hi,
> 
> Is there some kind of option substitution in unit configuration
> files?

Unit files are supposed to be simply configuration files, not a macro
language. That said there is:

1) Specifier expansion in a number of settings, resolving things like
   %i, %f, %b or %H. For a full list of these specifiers, please check
   systemd.unit(5), there's a whole section about it.

2) ExecStart= and friends support a limited form of env var
   substitution based on the env vars accumlated when the process
   specified is invoked, combining all env vars inherited from PID1,
   those set via Environment=, and EnvironmentFile= as well as a
   those set due to socket activation, watchdog settings, and a couple
   of other reasons.

Other forms of substituion are not available.

> In a service configuration file, I specify the PID file and would like
> to re-use its name, e.g.
>     PIDFile=/var/run/myservice.pid
>     ExecStartPre=/usr/bin/touch %PIDFile ; /bin/chown myuser %PIDFile

This is not supported. Sorry. If you really need this you'd have to
specify the path explicitly each time. That said, I'd always encourage
you to fix the daemon in question to make something like the above
unnecessary.

The general problem with doing generic subsituations like the above is
that the files cannot be parsed linearly. THis becomes particularly
visible if you think about subsitution order: is there suppsoed to be
a difference between specifying the two lines like the above or in the
reverse order? What do you do with cyclic substituion? And so on...

Of course, one could find answers to all these questions, that make
sense, but the simple act of asking these questions indicates that one
is firmaly in the area of macro languages then, and not simple
configuration files anymore...

Or in other words: consider using a proper macro language if you want
one, for example, m4 or so...

Lennart

-- 
Lennart Poettering, Red Hat