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

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Thu May 16 10:04:28 UTC 2019

>>> Lennart Poettering <lennart at poettering.net> schrieb am 16.05.2019 um 10:29
Nachricht <20190516082910.GA24042 at gardel-login>:
> On Do, 16.05.19 08:55, Ulrich Windl (Ulrich.Windl at rz.uni‑regensburg.de)
>> 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.

Sorry I don't get it: So the idea is to have different generators, depending
on the 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.

OK, so different generators.

> Please read up on the documentation.

Actually I have read it multiple times, but still is's not very helpful.

>> 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.

Is calling the generators logged (and maybe finishing the last generator,
too)? After boot I could not find a journal message regarding that.

>> 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.

So what is the preferred method when some package install adds new unit files?
systemctl daemon-reload?

>> 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.

You claim the generators are very special, but I don't get it. Sorry.

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

And you seem unable to explain why they are not what I thing they are.

>> 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.

And what creates those dependency links and when? It's OK to point me to the
correct manual page.

> 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

So "link messing"; it's the ugly part of systemd.

> 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.

Isn't it sufficient when a generated unit contains "Wants=" or similar? If I
have to mess with links, why does "Wants=" exist at all? Maybe its all
historical, I don't know.

Ulrich Windl

More information about the systemd-devel mailing list