Re: [systemd-devel] Unwants
On 27 January 2015 at 21:35, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Jan 27, 2015 at 10:30:48PM +0100, Lennart Poettering wrote: On Tue, 27.01.15 15:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Hmm, I am open to allowing to override the symlinks with symlinks, if you follow what I mean. But i'd be careful with allowing to override stuff listed in Wants= in a unit file in /usr, with a symlink in a .wants/ dir in /etc, if you follow what I mean. Yes, exactly. But yeah, allowing symlinks to override symlinks makes sense, a patch for that would be good. Lennart Zbyszek ack. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Thu, 22.01.15 13:54, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? When we designed this initially this way I wasn't sure this would suffice, but I kinda like the simplicity of this, and interestingly you are the first one who wants to reset dependencies again. Which makes me wonder if we canot find a better solution for this? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null Wat precisely is the reason for trying to do this? What are you trying to do here, and why? So, is there a way to unwant something, as an override? Nope, currently there isn't. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On 27 January 2015 at 12:42, Lennart Poettering lenn...@poettering.net wrote: On Thu, 22.01.15 15:16, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 22 January 2015 at 14:46, Michael Biebl mbi...@gmail.com wrote: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. Presets are good, however they do not have a format to specify extra .wants and .requires. And in my case unwants and unrequires. Extra .wants and .requires? What would those entail? I mean, the unit files can store extra deps in their [Install] section... So at the moment I'm playing around with - unconditionally running preset on my preset file, and directing users to write (override) own preset file in /etc/systemd/system-preset if they want to modify the default proposed integration. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. Well, if systemctl enable/disable/add-requires/add-wants would write things into /etc/systemd/system-preset instead of modifying things in /etc, then it would be alright. As essentially the full set of presets would be the state of system-defaults + user overrides. Also it seems like preset is a bit of templating hack at the moment, as they are not loaded by systemd but rarther are simply used to generate files/symlinks on disk under /etc. I don't follow. Presets are the recommended vendor configuration, and as such static and immutable. It is supposed to be applied once, during first installation of a pacakge. From that point on things are user configuration and presets will not be applied. The end result of preset commands is the same as running a series of enable/disable commands interactively. Which means it is never possible to tell apart differences between: admin changes, current vendor configuration, original vendor configuration at install-time. Nor upgrade to new vendor defaults. Thus preset files simply scrip a list of enable/disable commands to run. It is not supposed to be applied only once, but rather it has no way to distinguish user modifications vs old vendor config and thus cannot be re-run again without loosing admin changes/choices. E.g. for my use-case it would be awesome if preset commands would generate symlinks in e.g. /var/lib/systemd/preset-system/ That way preset files is the current vendor configuration, /var/lib/systemd/preset-system has symlinks as to how the system was configured at install time. Later when system is upgraded and e.g. vendor presets change, I would like to enable user to upgrade the install time config to the current one (by running preset command again, which would update symlinks in /var/lib/systemd/preset-system based on the new preset configuration) Or something like that. I'm working on a system which has a policy of units enabled by default, with packaging discouraged from shipping files in /etc. /etc is end-user modifiable however and is supported to store overrides over what is shipped in /usr. Patching preset files during runtime is really against what they were designed for. Quite frankly, I have trouble following at all what is being attempted here... I think i'll need to start again, or show/expain what I mean on Friday. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On 27 January 2015 at 12:38, Lennart Poettering lenn...@poettering.net wrote: On Thu, 22.01.15 14:08, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: In any case, /etc overrides /run, so your example can never work. Oh, ok. But any combination of the two. E.g. for /etc to unwant from /run then, or for /etc to unwant from /usr. At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it I am not grokking this. If you remove the package with the symlinks in /usr, then den deps are gone, so why do you need something in /etc or /run still? For the case when one cannot remove the package at runtime (i.e. /usr is read only) or there is no mechanism to remove packages at all (no package manager). -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, 27.01.15 15:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Hmm, I am open to allowing to override the symlinks with symlinks, if you follow what I mean. But i'd be careful with allowing to override stuff listed in Wants= in a unit file in /usr, with a symlink in a .wants/ dir in /etc, if you follow what I mean. But yeah, allowing symlinks to override symlinks makes sense, a patch for that would be good. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, Jan 27, 2015 at 10:30:48PM +0100, Lennart Poettering wrote: On Tue, 27.01.15 15:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Hmm, I am open to allowing to override the symlinks with symlinks, if you follow what I mean. But i'd be careful with allowing to override stuff listed in Wants= in a unit file in /usr, with a symlink in a .wants/ dir in /etc, if you follow what I mean. Yes, exactly. But yeah, allowing symlinks to override symlinks makes sense, a patch for that would be good. Lennart Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, 27.01.15 16:18, Christian Seiler (christ...@iwakd.de) wrote: Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. it's more complex than that, since dependencies can come from both sides, and are generated automatically even. If we really wanted this to work, we'd have store precisely if a dep belongs to the soource or the destaination of the dep, if a dep comes from configuration, or is automatically created, and that we never coalesce deps. But I am not I like the complexity of that, and in particular the fact that we couldn't coalesce anymore... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: On Thu, 22.01.15 13:54, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. For --user mode this is actually the only unprivileged way to achieve complete overriding of system supplied units, so I'm convinced we should allow this. Zbyszek When we designed this initially this way I wasn't sure this would suffice, but I kinda like the simplicity of this, and interestingly you are the first one who wants to reset dependencies again. Which makes me wonder if we canot find a better solution for this? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null Wat precisely is the reason for trying to do this? What are you trying to do here, and why? So, is there a way to unwant something, as an override? Nope, currently there isn't. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Christian [*] Probably, I haven't checked. ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, Jan 27, 2015 at 03:50:49PM +, Dimitri John Ledkov wrote: On 27 January 2015 at 15:18, Christian Seiler christ...@iwakd.de wrote: Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Well i thought that if below are implemented: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html Yeah, I think I dozed off at the of that discussion there, thank you for digging up the links. It seems everybody is in agreement about overriding .wants/.requires symlinks with /dev/null. ... Whilst: bar.service: [Unit] Wants=!foo.service foo.service: [Install]WantedBy=!bar But this isn't in the mails you linked. Let's get the link-overriding part done first. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Thu, 22.01.15 14:08, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: In any case, /etc overrides /run, so your example can never work. Oh, ok. But any combination of the two. E.g. for /etc to unwant from /run then, or for /etc to unwant from /usr. At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it I am not grokking this. If you remove the package with the symlinks in /usr, then den deps are gone, so why do you need something in /etc or /run still? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Thu, 22.01.15 15:16, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 22 January 2015 at 14:46, Michael Biebl mbi...@gmail.com wrote: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. Presets are good, however they do not have a format to specify extra .wants and .requires. And in my case unwants and unrequires. Extra .wants and .requires? What would those entail? I mean, the unit files can store extra deps in their [Install] section... So at the moment I'm playing around with - unconditionally running preset on my preset file, and directing users to write (override) own preset file in /etc/systemd/system-preset if they want to modify the default proposed integration. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. Well, if systemctl enable/disable/add-requires/add-wants would write things into /etc/systemd/system-preset instead of modifying things in /etc, then it would be alright. As essentially the full set of presets would be the state of system-defaults + user overrides. Also it seems like preset is a bit of templating hack at the moment, as they are not loaded by systemd but rarther are simply used to generate files/symlinks on disk under /etc. I don't follow. Presets are the recommended vendor configuration, and as such static and immutable. It is supposed to be applied once, during first installation of a pacakge. From that point on things are user configuration and presets will not be applied. Patching preset files during runtime is really against what they were designed for. Quite frankly, I have trouble following at all what is being attempted here... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On 27 January 2015 at 15:18, Christian Seiler christ...@iwakd.de wrote: Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Well i thought that if below are implemented: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html the logic would be: bar.service: [Unit] Wants=foo.service foo.service: [Install]WantedBy=bar bar.service.wants/foo.service - ***/foo.service Add a dependency type want from bar - to foo. Whilst: bar.service: [Unit] Wants=!foo.service foo.service: [Install]WantedBy=!bar bar.service.wants/foo.service - /dev/null Would remove a dependency link from bar - to foo, if and only if it already exists. The ! syntax is for e.g. overriding symlinks via .d/*.conf files or when unit is copied into a higher level configuration path and edited. Thus everything is still coalescing, in the order that configuration directories are transversed, but proposed to be additive and subtractive in nature. (and will thus allow adding/removing dependencies at each configuration level) e.g. distro ships user level unit that gpg-agent is enabled by default in the user sessions global user override by admin sets gnome-keyring to be the default agent for user sessions (Wants=gnome-keyring-gpg !gpg-agent) user overrides the admin to make gpg-agent enabled by default back (Wants=!gnome-keyring-gpg gpg-agent) where wants are either .d snippets with lines as in brackets or (valid | dev-null) symlinks in appropriate .wants directories at respective configuration levels. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On 27 January 2015 at 16:47, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Jan 27, 2015 at 03:50:49PM +, Dimitri John Ledkov wrote: On 27 January 2015 at 15:18, Christian Seiler christ...@iwakd.de wrote: Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Well i thought that if below are implemented: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html Yeah, I think I dozed off at the of that discussion there, thank you for digging up the links. It seems everybody is in agreement about overriding .wants/.requires symlinks with /dev/null. cool. ... Whilst: bar.service: [Unit] Wants=!foo.service foo.service: [Install]WantedBy=!bar But this isn't in the mails you linked. Let's get the link-overriding part done first. Yeah, that's my new proposal as extension to above, to keep .d as capable as .wants/.requires. Sure, I'll keep this open for discussion/agreement and will not be implementing just yet. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On 22 January 2015 at 16:32, Andrei Borzenkov arvidj...@gmail.com wrote: В Thu, 22 Jan 2015 15:46:26 +0100 Michael Biebl mbi...@gmail.com пишет: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. There was long discussion on this just recently. http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.html Thanks for this. The summary of that follows like so: generic/typical systemd units ship, with a Install section WantedBy multi-user.target an no other files. It means it is inert / disabled by default. Irrespective of the method (preset-all on empty/wiped /etc, preset at first install only, enable (generated in packaging or run by an admin), the way to enable unit is by generating appropriate .wants/ symlinks in /etc. It is viewed that distos should use presets whilst admins should use enable, however the end result is the same on disk. (E.g. distros can script things around enable/disable, and admins can write /etc/systemd/system-preset and run preset from that file). There are claims and assertions made as to what distro's should and shouldn't do - which are distro's decisions. It is not possible to encode distro's choices with the suggested or possible semantics, neither with presets nor shipping symlinks in /usr. Then end-result is that current semantics have a bias towards disable * default policy. (Unit by itself is not enabled, default policy not enable, if user or preset enables, it is stored in admin dir /etc, rather than state dirs under /var) The worst consequence of this, imho, is that .wants symlinks are honoured from lower level directories even if the unit is out right superseeded in a higher level directory. E.g. cp /usr/lib/systemd/system/foo*.target /etc/systemd/system; the /usr/lib/systemd/system/foo1.target.wants/foo2.target - ../foo1.target is honoured. Nor is there a way to move a wants to a later target in the boot process. (e.g. most systemd intuitive way to add symlink to /dev/null have systectl commands that mirror add-wants/add-requires) Furthermore, it appears that /etc is used as a snapshot of the preset state as it was at the last time preset-all was run essentially. On my books software state should live under /var rather under /etc. And in the current generation philosophy this breaks the assumption that /etc is user modified overrides only. But I think we can do better than /var. Do we really need symlinks on disk from presets? Here is a proposal: extend .wants/*; .requires/* semantics to allow removal: e.g. if the target of the symlink in .wants/ directory points at /dev/null, instead of adding a dependency, such dependency is removed if it no longer exists e.g. Wants/Requires define dependencies to be added, or negating a dependency if such already exists if prefixed with ! e.g. add commands rm-wants / rm-requires - which either create symlink to /dev/null in /etc/***.wants/ for dependencies created in lower-level configuration directories or removes existing symlink from /etc/***.wants/ remove preset-* commands, or support mode of operation where preset commands are no-op. instead load and apply (on boot, daemon-reload, daemon-reexec) preset directives in memory without storing a snapshot of preset results as symlinks in /etc. (this would make systemd stateless and be operational with less symlinks on an even a read-only /etc without even a tmpfs rw mounted /etc) This makes the policies of enable * and disable * to be in full equilibrium: - default policy applied from /usr - user override is .wants/* symlinks based on Install section -- to /dev/null to disable under enable * policy -- to a valid unit to be enabled under disable * policy -- no change in system under /usr (intentional or accidental) would loose user choice This would lead to one-time upgrade loss of state for disable * distributions (i.e. the small number of distro enabled by default units, which were disabled by the users, would get re-enabled. As a one time upgrade, this can be detected and acted upon appropriately). However this one time upgrade / miss-balance exaggerates the complexity inflicted upon enable * distributions where this problem is not for small number of
Re: [systemd-devel] Unwants
On 22 January 2015 at 14:00, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jan 22, 2015 at 01:54:37PM +, Dimitri John Ledkov wrote: Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null to cancel /etc/systemd/system/getty.target.wants/getty@tty1.service - ../../../../usr/lib/systemd/system/getty@.service However i've found that the target of the symlink does not matter, and thus symlinks to /dev/null in .wants directory enable the dependencies. One can experiment with just dummy foo.target and bar.target in /etc/systemd/system. Similarly I've tried adding .d snippet with Wants=!unwanted.service but that only failed to load the snippet... So, is there a way to unwant something, as an override? IIRC, we had a discussion about that, but I don't remember the result. If anyone has topic names / mailing-list urls i'd be glad for those to be pointed out. In any case, /etc overrides /run, so your example can never work. Oh, ok. But any combination of the two. E.g. for /etc to unwant from /run then, or for /etc to unwant from /usr. At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Thu, Jan 22, 2015 at 01:54:37PM +, Dimitri John Ledkov wrote: Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null to cancel /etc/systemd/system/getty.target.wants/getty@tty1.service - ../../../../usr/lib/systemd/system/getty@.service However i've found that the target of the symlink does not matter, and thus symlinks to /dev/null in .wants directory enable the dependencies. One can experiment with just dummy foo.target and bar.target in /etc/systemd/system. Similarly I've tried adding .d snippet with Wants=!unwanted.service but that only failed to load the snippet... So, is there a way to unwant something, as an override? IIRC, we had a discussion about that, but I don't remember the result. In any case, /etc overrides /run, so your example can never work. zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unwants
Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null to cancel /etc/systemd/system/getty.target.wants/getty@tty1.service - ../../../../usr/lib/systemd/system/getty@.service However i've found that the target of the symlink does not matter, and thus symlinks to /dev/null in .wants directory enable the dependencies. One can experiment with just dummy foo.target and bar.target in /etc/systemd/system. Similarly I've tried adding .d snippet with Wants=!unwanted.service but that only failed to load the snippet... So, is there a way to unwant something, as an override? -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
В Thu, 22 Jan 2015 15:46:26 +0100 Michael Biebl mbi...@gmail.com пишет: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. There was long discussion on this just recently. http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On 22 January 2015 at 14:46, Michael Biebl mbi...@gmail.com wrote: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. Presets are good, however they do not have a format to specify extra .wants and .requires. And in my case unwants and unrequires. So at the moment I'm playing around with - unconditionally running preset on my preset file, and directing users to write (override) own preset file in /etc/systemd/system-preset if they want to modify the default proposed integration. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. Well, if systemctl enable/disable/add-requires/add-wants would write things into /etc/systemd/system-preset instead of modifying things in /etc, then it would be alright. As essentially the full set of presets would be the state of system-defaults + user overrides. Also it seems like preset is a bit of templating hack at the moment, as they are not loaded by systemd but rarther are simply used to generate files/symlinks on disk under /etc. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. Michael [1] https://packages.debian.org/search?keywords=init-system-helpers -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
