[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
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)
>> 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?
> This is explained in the documentation btw:
> 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?
>> What makes your generators special? That they have no explicitly
>> settable dependencies, or that they are called with three directory
> 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.
More information about the systemd-devel