Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Do, 16.05.19 12:04, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > 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? No. As explained in the documentation: sometimes you want to generate dynamic unit files that override the regular unit files (think: overriding the boot target the system shall boot into). Sometimes you want that regular unit files override the dynamic ones (think: you automaticlly convert sysv scripts to native unit files, but if a regular unit file already exists for a service you want that to take precedence, since native should be better than converted). All generators are run at the same time btw, there's no ordering between them. > >> 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. Nope, please read the documentation. it's very clearly explained there. It's about precendence relative to installed regular unit files. > > Please read up on the documentation. > > Actually I have read it multiple times, but still is's not very > helpful. Sorry, but it doesn't appear like you did... > Is calling the generators logged (and maybe finishing the last generator, > too)? After boot I could not find a journal message regarding that. Turn on debug logging, and it is. i.e. add systemd.log_level=debug to the kernel command line. > > 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? Yes. That's the command to invoke whenever you remove or drop in unit files into the directories in /usr/lib/systemd/system or /etc/systemd/system or similar. > >> 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. They run in an early boot environment outside of any service management, snce they generate service definitions. That makes them kinda special. See the long list of dos/donts in the documentation. https://www.freedesktop.org/software/systemd/man/systemd.generator.html > > 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. I am sorry, but this gets on my nerves. Yes, our documentation is not perfect (which documentation is?) but you appear unable to read even the most basic parts of it, since most of what you are asking is actually documented in the various linked docs. Please, when you are new to systemd, start with the simple things first, and as you grokked them continue with the more complex stuff. You are jumping to the advanced stuff from zero apparently, without understanding the basic concepts the advanced stuff builds on. Of course things are going to be frustrating if you do that, but maybe the fix to that is starting to reading up on the basics first! You receieved an awful lot of free help here even though when you came onto the mailing list you started out with telling evreyone how awful systemd is. You are using up all my patience slowly but surely, and if you continue like that you'll notice the responses you get will be fewer and fewer. > And what creates those dependency links and when? It's OK to point me to the > correct manual page. For units installed via packages in /usr/lib/systemd/system or by the user in /etc/systemd/system these links are created by "systemctl enable". You can also create them maualy if you like, that's fine. That maps 1:1: how tools such as update-rc.d or chkconfig did things on the various distros back in sysvinit times. If you write a generator then its the generator that creates the symlinks. But again, generators are an advanced topic, and you shouldn't use them unless you really really know what you are doing. https://www.freedesktop.org/software/systemd/man/systemctl.html#enable%20UNIT%E2%80%A6 > > the right places. systemctl can't guess that. I mean, if a service > > So "link messing"; it's the ugly part of systemd. What's so hard about using "systemctl enable"? I mea
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Thu, May 16, 2019 at 12:04:28PM +0200, Ulrich Windl wrote: > >>> Lennart Poettering 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? Please, this is just wasting everyone's time. Take the advice that Reindl gave you: generators are an advanced tool that you don't need when staring with systemd. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering 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 systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
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. 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. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
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? 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) Also: the only thing that might prevent using a generator for dynamic configuration is that it is called early during boot. 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? What makes your generators special? That they have no explicitly settable dependencies, or that they are called with three directory arguments? 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. Regards, Ulrich >>> Lennart Poettering 05/15/2019, 12:22 PM >>> On Mi, 15.05.19 12:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > I mean, if you want to persistently enable a unit that is converted > > from something else, then please write your own converted, and write > > something to /etc/systemd/system, there's no need whatsoever to bother > > systemd itself with that, you shouldn't use generators for that. > > Sorry, I still don't get it: The only(?) difference is the path where they > (units files) are found, and that the /run directory is volatile. Aren't the > other differences not just "artificial"? Please see: https://www.freedesktop.org/software/systemd/man/systemd.generator.html i.e. generators are invoked whenever a reload cycle begins, and output their units into a specific directories that are flushed our when the reload cycle ends. i.e. everytime "systemctl daemon-reload" is invoked the files generated on the current cycles are removed, and the generators started again to generate a new set of files. Whateever they generate has very clear, very volatile semantics: issue "systemctl daemon-reload" and its all gone. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Wed, 2019-05-15 at 10:03 +, systemd-devel- requ...@lists.freedesktop.org wrote: > > > If you are looking for a generic converter of foreign stuff into > classic, persistent systemd unit files, then generators is not what > you should be using. Generators are life-cycle bound to systemd > release cycles, and their output ceases to exist on every reload > boundary, and when the system is offline. If we'd allow generated > units to be installed that clear life-cycle would be very much > blurred, as suddenly you'd have configuration that hooks them into the > system that is more persistant than the actual definitions of the > units themselves, and that's just borked... > > I mean, if you want to persistently enable a unit that is converted > from something else, then please write your own converted, and write > something to /etc/systemd/system, there's no need whatsoever to bother > systemd itself with that, you shouldn't use generators for that. > As an embedded Linux developer, I think there is an interesting idea here. There are no admins on an embedded system and everything must be done through some automatic piece of software. As soon I see, "edit a file in /etc," I know there's a problem I'll need to find a solution for because the normal way isn't going to work. Embedded likes read-only root filesystems. We also like it if software image we create is immutable. So copying /etc out of a read-only filesystem into a writable one isn't really a solution to the problems posed by a read-only rootfs, as it largely defeats the purpose of making the rootfs read-only in the first place. I want the device configuration to be transactional. I want it to be safe from power cycles as it's updated. There should be roll-backs to previous configs, exporting configuration, importing it, pushing changes to a fleet of devices, automatic migration forward and backward across software versions. This is hard to do with a pile of text files in /etc all in different formats and parsed by different software. I think of all the ways one might configure services locally. Edit environment files read by units, edit the service files, etc. What if I dynamically generated service files? There's a lot that could be done that way. I can sort of dynamically enable units by starting them over dbus. But that really only works after most of the boot is done. What if I want to dynamically alter the CapabilityBoundingSet based on what features of a service are enabled? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
Am 15.05.19 um 13:12 schrieb Ulrich Windl: >> Well, there can always be more examples, but "generators" are >> inherently an advanced concept: if you are writing a generator, then >> you already should be pro enough to be able to consult the sources of >> the various generators shipped with systemd. >> >> i.e. it's not a beginners topic, it's a very low-level, technicallly >> advanced one. > > But you can assume that someone reading the manual page about generators wants > to ...well... read about generators. > Otherwise you could shorten the manual page to "Go away! You are not supposed > to read this." don't get me wrong but as you are a beginner to systemd stuff why don't you just start with ordinary unit files in /etc/systemd/system as erevrybody else does so you can get warm with systemd, systemctl and so on? i use systemd now for 7 years on all sort of setups from firewalls over workstations to production servers and wrote a ton of systemd units and targs but never had any need to even consider generators at all ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering schrieb am 15.05.2019 um 12:20 in Nachricht <20190515102024.GB23038@gardel-login>: > On Mi, 15.05.19 12:12, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) > wrote: > >> >>> Lennart Poettering schrieb am 15.05.2019 um 12:04 >> in >> Nachricht <20190515100400.GB22945@gardel-login>: >> > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) >> wrote: >> > >> >> > Writing a generator is not a typical user would do. It's what a >> >> > developer of a package would do, and yes, in that case, when you write >> >> > code you need a bit more understanding of the underpinnings and need >> >> > to do more work. >> >> >> >> systemd.generator(7) could really need some (better/realistic) examples. >> > >> > I think you assume generators are something they inherently are not. >> >> Even if so, a better example might clarify things. Just referring to a > binary >> generator like systemd-fstab-generator is not really helpful to teach how to >> write a generator. You don't like scripts as generators, but I think still > they >> would make a good example what a generator is supposed to do and what not. > > Well, there can always be more examples, but "generators" are > inherently an advanced concept: if you are writing a generator, then > you already should be pro enough to be able to consult the sources of > the various generators shipped with systemd. > > i.e. it's not a beginners topic, it's a very low-level, technicallly > advanced one. But you can assume that someone reading the manual page about generators wants to ...well... read about generators. Otherwise you could shorten the manual page to "Go away! You are not supposed to read this." Rehgards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Mi, 15.05.19 12:12, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Lennart Poettering schrieb am 15.05.2019 um 12:04 > in > Nachricht <20190515100400.GB22945@gardel-login>: > > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) > wrote: > > > >> > Writing a generator is not a typical user would do. It's what a > >> > developer of a package would do, and yes, in that case, when you write > >> > code you need a bit more understanding of the underpinnings and need > >> > to do more work. > >> > >> systemd.generator(7) could really need some (better/realistic) examples. > > > > I think you assume generators are something they inherently are not. > > Even if so, a better example might clarify things. Just referring to a binary > generator like systemd-fstab-generator is not really helpful to teach how to > write a generator. You don't like scripts as generators, but I think still > they > would make a good example what a generator is supposed to do and what not. Well, there can always be more examples, but "generators" are inherently an advanced concept: if you are writing a generator, then you already should be pro enough to be able to consult the sources of the various generators shipped with systemd. i.e. it's not a beginners topic, it's a very low-level, technicallly advanced one. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Mi, 15.05.19 12:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > I mean, if you want to persistently enable a unit that is converted > > from something else, then please write your own converted, and write > > something to /etc/systemd/system, there's no need whatsoever to bother > > systemd itself with that, you shouldn't use generators for that. > > Sorry, I still don't get it: The only(?) difference is the path where they > (units files) are found, and that the /run directory is volatile. Aren't the > other differences not just "artificial"? Please see: https://www.freedesktop.org/software/systemd/man/systemd.generator.html i.e. generators are invoked whenever a reload cycle begins, and output their units into a specific directories that are flushed our when the reload cycle ends. i.e. everytime "systemctl daemon-reload" is invoked the files generated on the current cycles are removed, and the generators started again to generate a new set of files. Whateever they generate has very clear, very volatile semantics: issue "systemctl daemon-reload" and its all gone. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering schrieb am 15.05.2019 um 12:04 in Nachricht <20190515100400.GB22945@gardel-login>: > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> > Writing a generator is not a typical user would do. It's what a >> > developer of a package would do, and yes, in that case, when you write >> > code you need a bit more understanding of the underpinnings and need >> > to do more work. >> >> systemd.generator(7) could really need some (better/realistic) examples. > > I think you assume generators are something they inherently are not. Even if so, a better example might clarify things. Just referring to a binary generator like systemd-fstab-generator is not really helpful to teach how to write a generator. You don't like scripts as generators, but I think still they would make a good example what a generator is supposed to do and what not. Regards, Ulrich > > Lennart > > ‑‑ > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering schrieb am 15.05.2019 um 12:03 in Nachricht <20190515100311.GA22945@gardel-login>: > On Mi, 15.05.19 11:57, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> >> could call "systemctl add‑wants ‑‑transient" to do the job, >> >> but at that point, that's more pedantic than practical. If you write a >> >> generator, your systemd‑fu should be high enough to know and >> >> understand systemd's symlink mechanisms... >> > >> > Precisely. if you write your own generator, then you need to know what >> > you do, and need to know how to place your symlinks. You are >> > essentially writing your own unit file installer that way and are >> > expected to create your own symlinks then. >> >> I didn't see it that way: Generated units are just as units installed by > some >> package manager, but specific to the local configuration. So why to make >> differences?: A unit is a file that is found by systemd (after the > generators >> finished)... > > Nope, that's simply not how they are designed. They are a mechanism > how to extend the systemd dependency tree and install additional > nodes in that tree. > > If you are looking for a generic converter of foreign stuff into > classic, persistent systemd unit files, then generators is not what > you should be using. Generators are life‑cycle bound to systemd > release cycles, and their output ceases to exist on every reload > boundary, and when the system is offline. If we'd allow generated > units to be installed that clear life‑cycle would be very much > blurred, as suddenly you'd have configuration that hooks them into the > system that is more persistant than the actual definitions of the > units themselves, and that's just borked... > > I mean, if you want to persistently enable a unit that is converted > from something else, then please write your own converted, and write > something to /etc/systemd/system, there's no need whatsoever to bother > systemd itself with that, you shouldn't use generators for that. Sorry, I still don't get it: The only(?) difference is the path where they (units files) are found, and that the /run directory is volatile. Aren't the other differences not just "artificial"? > > Lennart > > ‑‑ > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > Writing a generator is not a typical user would do. It's what a > > developer of a package would do, and yes, in that case, when you write > > code you need a bit more understanding of the underpinnings and need > > to do more work. > > systemd.generator(7) could really need some (better/realistic) examples. I think you assume generators are something they inherently are not. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
On Mi, 15.05.19 11:57, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >> could call "systemctl add-wants --transient" to do the job, > >> but at that point, that's more pedantic than practical. If you write a > >> generator, your systemd-fu should be high enough to know and > >> understand systemd's symlink mechanisms... > > > > Precisely. if you write your own generator, then you need to know what > > you do, and need to know how to place your symlinks. You are > > essentially writing your own unit file installer that way and are > > expected to create your own symlinks then. > > I didn't see it that way: Generated units are just as units installed by some > package manager, but specific to the local configuration. So why to make > differences?: A unit is a file that is found by systemd (after the generators > finished)... Nope, that's simply not how they are designed. They are a mechanism how to extend the systemd dependency tree and install additional nodes in that tree. If you are looking for a generic converter of foreign stuff into classic, persistent systemd unit files, then generators is not what you should be using. Generators are life-cycle bound to systemd release cycles, and their output ceases to exist on every reload boundary, and when the system is offline. If we'd allow generated units to be installed that clear life-cycle would be very much blurred, as suddenly you'd have configuration that hooks them into the system that is more persistant than the actual definitions of the units themselves, and that's just borked... I mean, if you want to persistently enable a unit that is converted from something else, then please write your own converted, and write something to /etc/systemd/system, there's no need whatsoever to bother systemd itself with that, you shouldn't use generators for that. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering schrieb am 15.05.2019 um 11:54 in Nachricht <20190515095443.GA22887@gardel-login>: > On Mi, 15.05.19 12:47, Andrei Borzenkov (arvidj...@gmail.com) wrote: > >> > > localhost:~ # systemctl enable usr‑local.mount >> > > Failed to enable unit: Unit /run/systemd/generator/usr‑local.mount is >> > > transient or generated. >> > > localhost:~ # exit >> > >> > Hmm? >> > >> > No? Why? >> >> You just said that "You should never need to. [mess with symlinks]. >> For all relevant operations there are "systemctl"". > > Yeah, for all user‑facing operations. > > Writing a generator is not a typical user would do. It's what a > developer of a package would do, and yes, in that case, when you write > code you need a bit more understanding of the underpinnings and need > to do more work. systemd.generator(7) could really need some (better/realistic) examples. > >> > generated units cannot be enabled, what am I missing? >> >> You are apparently missing context to which you replied. This >> discussion *is* about enabling generated units. Of course, we now >> again have problem that everyone implies different meaning of >> "enabled". To avoid this word altogether ‑ generated unit can only be >> included in initial transaction if it is dependency of some other unit >> (already included in original transaction). You just claimed that to >> establish such dependency one should use systemctl and I demonstrated >> that this does not work. Either your claim is wrong, or the observed >> behavior is a bug. > > Again, generators are written by developers, not regular users doing > day‑to‑day work. They assumed to be enabled as the developers intend > them to, and that's orthogonal to the manual enable/disable scheme > that applies to regular, package‑shipped, file‑based units... > > Lennart > > ‑‑ > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
>>> Lennart Poettering schrieb am 15.05.2019 um 11:31 in Nachricht <20190515093135.GF22719@gardel-login>: > On Mi, 15.05.19 11:29, Jérémy ROSEN (jeremy.ro...@smile.fr) wrote: > >> well, in another thread, it was discussed why generated should never have >> an install section and why enablement does not make sense for them... >> so no it's not a bug. >> >> Arguably, yes, generators do need to care about symlinks, though, maybe the >> could call "systemctl add-wants --transient" to do the job, >> but at that point, that's more pedantic than practical. If you write a >> generator, your systemd-fu should be high enough to know and >> understand systemd's symlink mechanisms... > > Precisely. if you write your own generator, then you need to know what > you do, and need to know how to place your symlinks. You are > essentially writing your own unit file installer that way and are > expected to create your own symlinks then. I didn't see it that way: Generated units are just as units installed by some package manager, but specific to the local configuration. So why to make differences?: A unit is a file that is found by systemd (after the generators finished)... > > Lennart > > -- > Lennart Poettering, Berlin > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
