Re: Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 16.05.2019 um 10:29
in
Nachricht <20190516082910.GA24042@gardel-login>:
> On Do, 16.05.19 08:55, Ulrich Windl (Ulrich.Windl@xxxxxx‑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.

The manual page says (contradicting IMHO): "This will rerun all generators
(see systemd.generator(7)), reload all unit files, and recreate the entire
dependency tree."

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

The manual page as I find it leaves a lot of guessing.

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel