Re: Configuring units (Was: Re: Can I use an EnvironmentFile to configure a Timer?)

[Lennart Poettering <mzxreary@xxxxxxxxxxx>]

On Do, 22.08.24 14:44, Gesh (gesh@xxxxxxxxxxx) wrote:

> On Thu, Aug 22, 2024 at 11:26:24AM GMT, Lennart Poettering wrote:
> > We only do env var expansion in ExecStart= and related line
> > types. Nothing else. (And I think it actually was a mistake there too.)
>
> This and other recent discussions[1] make me wonder what the intended
> balance is of which parts of units are configured where.
>
> As far as I'm aware, there are five ways to modify a unit's behaviour:
> - Instance names. These are relatively inflexible, but can be
>   supplemented by referring to files like `%E/%n/%i` to be able to
>   configure any given profile.
> - Adding to its environment. This is sometimes supplemented by using
>   Exec*'s envvar expansion which you discourage above (could you
>   elaborate why you consider it a misfeature? Is it because envvars
>   are a hard-to-track bit of context?).

envvars have strange semantics, and are inherited down the tree. Also,
it means that understanding what a unit file does is complex, because
it becomes a half-assed macro language, which is resolved at execution
time (instead of parsing time, like % specifiers are).

> - Drop-ins. On the one hand, these give near-complete control,
>   allowing you to overwrite most directives. On the other, the absence
>   of certain features (cf [2], [3]) suggests some usages are
>   discouraged, though it isn't clear which.

Frankly, modifying ExecStart= is more than "configuration" really, you
start changing codeflow there. It indicates that there's something
weird about the daemon, i.e. it doesn't properly separate its
configuration from its code flow.

> - Additional units whose runtime is scoped to lie within that of the
>   configured unit (cf [1]). The semantics of this are unclear to me,
>   but I get the vague sense this should be used for cases where extra
>   features can be implemented on top of the existing unit?

if you want to start some additional unit if some unit is started,
then the suggested approach works fine. But that's not "configuration"
either, it's changing of code flow.

> - Wrapping the executable in a script that'll parse a configuration
>   file and run the executable with a modified commandline/environment.
>   Most flexible, but would seem to fly in the face of the intent to
>   obsolete the use of shell scripts in the init process?

If you need to do this, then this too indicates that there's something
wonky with your daemon, and it probably should be fixed to properly
separate code and configuration.

> I would appreciate guidance on the recommended balance, especially in
> the following usecases:
> - The "local variables" case mentioned above
> - Adding a state load/save feature, as mentioned in [1]
> - OP's usecase of configuring the timer frequency
> - (Academic, but possibly illustrative): cf [4] -- adding flags to an
>   Exec* command line

You seem to look for a way to modify a lot more than the execution
context configuration. You appear to be wanting to dynamically
assemble command lines, or glueing app-specfic configuration files
into something lacking them. But neither of that is systemd's
business. A well written daemon should not require that, it should
have a static command line and read its settings from a config file of
some kind, with nothing in front of it.

Or to say this differently: if you are looking for glue scripting,
i.e. for a shell, then use a shell. systemd is not one. It generally
assumes its units wrap reasonably well written daemons, that behave
like a UNIX daemon would behave.

Lennart

--
Lennart Poettering, Berlin