>>> Lennart Poettering <lenn...@poettering.net> schrieb am 16.05.2019 um 10:29 in Nachricht <20190516082910.GA24042@gardel-login>: > On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@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.
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. Regards, Ulrich Windl _______________________________________________ systemd-devel mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel