>>> 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. > >> 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 email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel