[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Lennart Poettering]

On Do, 16.05.19 08:55, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> Hi!
>
> After having read the page again, it's not more clear than
> before. Even I have some more questions:
>
> Why do generators receive three directory paths: Should the
> generator decide where at those three paths to add a unit?

Yes.

This is explained in the documentation btw:
https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Long story short: it's about unit file precedence.

> How should it know? Wouldn't it be easier to provide one path and
> adjust that as necessary? (My generator just uses the first path)

It's up to the generator to decide whether it wants to override native
unit files already in place, or whether it wants those to override
whatever it generates.

Please read up on the documentation.

> Also: the only thing that might prevent using a generator for
> dynamic configuration is that it is called early during boot.

Generators follow the reload cycle, and the reload cycle is how the
reload cycle is.

> So I could have a generator that just saved the three paths
> somewhere, and a unit that calls "another generator" that is not
> detected as a systemd generator using the paths saved before to
> generate the unit files and do a "systemctl reload-daemon" (watching
> out for possible indirect recursion). But why the dance?

Doing "systemctl daemon-reload" in clean codepaths is possible but not
good style. It's slow and problematic since Linux doesn't really have
a transactional fs, and thus you never know in which precise state the
fs is when systemd reloads things in case multiple programs make
modifications to the unit files at the same time.

> What makes your generators special? That they have no explicitly
> settable dependencies, or that they are called with three directory
> arguments?

I am not sure how to parse that.

As I mentioned before: you appear to think that generators are
something they are clearly not.

> And what about the "link stuff": Doesn't reload-daemon create those
> as needed from the unit files? Why should the generator have to mess
> with those? It's all not clear from the manual page. The only thing
> I can imagine is that those "link messing" is needed to provide
> functionality the systemd actually lacks.

daemon-reload just reloads configuation, it does not create or remove
any symlinks.

It's your generator's job to hook the units it might generate into
the right places. systemctl can't guess that. I mean, if a service
shall be started during regular boot, or if it shall be hooked into
getty.target or when bluetooth hw is plugged in is nothing systemd can
guess for you.

Lennart

--
Lennart Poettering, Berlin