Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On Sun, 19.04.15 09:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. Actually it's not that easy. You need to collect the deps created from unit configuration into a set of hashmaps of their own, and then add a final commit step that merges those into the real deps. And if we want to do this without needless copies and allocations this is actually not easy at all. 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] Another attempt: Making dependencies properly overridable
On Mon, 16.02.15 16:19, Christian Seiler (christ...@iwakd.de) wrote: Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) Sounds good. I like. +1. Me gusta. - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. I figure I can agree with this, too. The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Actually I'd probably be more liberal here and even allow dropping deps created in the unit file with a .wants masking. The only thing i would not allow is masking out deps on a unit that are actually configure on another unit, as well as automatic deps. I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. 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] Another attempt: Making dependencies properly overridable
On Sun, 19.04.15 17:08, Andrei Borzenkov (arvidj...@gmail.com) wrote:
What about Wants-=e.service in dropin? Dropins are processed
after .{wants,requires}.d and has advantage that you can remove also
static dependency from unit definition file, not only mask another
directory.
This has been requested before, but I'd be very careful with this. I
really don't want to turn this into a complex language really, and
especially not in one that knows different kinds of assignments. I
mean, already we aren't simple .ini files anymore, since we allow
assigning the empty string for resets, and allow multiple assignments
that add things up. But I'd *really* like to avoid deviating even
further from the simplicity that ini files are.
Or let's say it like this: I am very keen on keeping the file
structure as simple as just a list of key-value pairs, possibly with
[sections] and comments, and that's it.
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] Another attempt: Making dependencies properly overridable
On 04/23/2015 08:36 PM, Lennart Poettering wrote: I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. That makes sense, I'll incorporate that. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On 04/23/2015 08:38 PM, Lennart Poettering wrote: On Sun, 19.04.15 09:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. Actually it's not that easy. You need to collect the deps created from unit configuration into a set of hashmaps of their own, and then add a final commit step that merges those into the real deps. And if we want to do this without needless copies and allocations this is actually not easy at all. Yes, I know, because I'm currently working on a patch for this. ;-) I'll probably send a first version in a couple of days. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On 23 April 2015 at 14:58, Christian Seiler christ...@iwakd.de wrote: On 04/23/2015 08:36 PM, Lennart Poettering wrote: I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. That makes sense, I'll incorporate that. I like this as well. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center 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] Another attempt: Making dependencies properly overridable
On Sun, Apr 19, 2015 at 09:29:55AM +0300, Andrei Borzenkov wrote: В Fri, 17 Apr 2015 16:47:58 + Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote: Am 2015-02-16 14:16, schrieb Lennart Poettering: On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... [...] Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. A more complex example to illustrate the latter: /usr/lib/.../a.service: [Unit] Wants=b.service After=c.service /usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service /usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service /usr/lib/.../f.service [Unit] Before=a.service /etc/.../a.service.d/dont-depend-on-b.conf: [Unit] Wants= /etc/.../a.service.d/not-after-c.conf: [Unit] After= /etc/.../a.service.wants/e.service - /dev/null In the end, the dependnecies should be: Wants=d.service - b.service gets removed via drop-in - e.service gets removed because it's masked - but d.service stays, because it was never defined in the unit file, so a drop-in doesn't override it, only the mask does After=f.service - c.service gets removed via drop-in - f.service is not declared in the original unit file but rather in f.service as a Before= dependency, so you'd have to override that to make this go into effect The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Would you be agreeable to these semantics? If so, I'll hack up a patch. Seems quite intuitive to me. Would be great to have this implemented. Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. Also links in .wants and .requires can be masked. It's not a huge change, but I not trivial either -- and this part of the code is notriously had to get right. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
В Fri, 17 Apr 2015 16:47:58 + Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote: Am 2015-02-16 14:16, schrieb Lennart Poettering: On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... [...] Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. A more complex example to illustrate the latter: /usr/lib/.../a.service: [Unit] Wants=b.service After=c.service /usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service /usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service /usr/lib/.../f.service [Unit] Before=a.service /etc/.../a.service.d/dont-depend-on-b.conf: [Unit] Wants= /etc/.../a.service.d/not-after-c.conf: [Unit] After= /etc/.../a.service.wants/e.service - /dev/null In the end, the dependnecies should be: Wants=d.service - b.service gets removed via drop-in - e.service gets removed because it's masked - but d.service stays, because it was never defined in the unit file, so a drop-in doesn't override it, only the mask does After=f.service - c.service gets removed via drop-in - f.service is not declared in the original unit file but rather in f.service as a Before= dependency, so you'd have to override that to make this go into effect The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Would you be agreeable to these semantics? If so, I'll hack up a patch. Seems quite intuitive to me. Would be great to have this implemented. Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
В Sun, 19 Apr 2015 13:19:37 +
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
On Sun, Apr 19, 2015 at 09:29:55AM +0300, Andrei Borzenkov wrote:
В Fri, 17 Apr 2015 16:47:58 +
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote:
Am 2015-02-16 14:16, schrieb Lennart Poettering:
On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote:
Not quite. While you can use drop-in snippets to amend
orderings/depends, it's (unfortunately) not possible to override
Wants=,Before= etc.
There have been discussions to allow masking deps via /dev/null
symlinks in .wants/ and .requires/ dirs... I think that'd be a better
solution...
[...]
Agreed, systemctl edit is much nicer. Unfortunately, as said above,
drop-ins can *not* be used to override all aspects of a native unit
file. So it's not (yet) a complete replacement for insserv
overrides.
If it would be possible to unset Wants= or After=, just like other
service properties, then things would be different.
As mentioned, I'd be happy to take patches to make precisely that
work!
Last time I talked about this here, there was a lot of confusion, so
I didn't pursue it further. But I would really like to get this to
work, but before I start with a patch, I'd like to explain what I'd
like to do before working on it, to see if it works for you.
The semantics I'd like to see would be the following:
- anything in /etc named exactly the same as in /usr/lib overrides
the latter, just as is already the case with units and drop-ins
= allow masking of .wants/ and .requires/ with symlinks to
/dev/null (I think you were in favor of that)
- additionally, postpone processing of dependencies in unit files
until the entire unit (and all drop-ins) have been read in
For example, even without a drop-in:
a.service:
[Unit]
Wants=b.service
Wants=
Wants=c.service
After that, Wants should be set to c.service. Note that this
should NOT affect dependencies set in other ways, i.e. via
.wants/ directories or by dependencies of other services, this
should JUST alter what was specified in the unit itself.
A more complex example to illustrate the latter:
/usr/lib/.../a.service:
[Unit]
Wants=b.service
After=c.service
/usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service
/usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service
/usr/lib/.../f.service
[Unit]
Before=a.service
/etc/.../a.service.d/dont-depend-on-b.conf:
[Unit]
Wants=
/etc/.../a.service.d/not-after-c.conf:
[Unit]
After=
/etc/.../a.service.wants/e.service - /dev/null
In the end, the dependnecies should be:
Wants=d.service
- b.service gets removed via drop-in
- e.service gets removed because it's masked
- but d.service stays, because it was never defined in
the unit file, so a drop-in doesn't override it, only
the mask does
After=f.service
- c.service gets removed via drop-in
- f.service is not declared in the original unit file but
rather in f.service as a Before= dependency, so you'd
have to override that to make this go into effect
The general principle would be: you can drop stuff at the same
place it's defined. If it's defined as After= in a unit,
override it in a drop-in for that unit, if it's defined as
Before= in another unit, override it in a drop-in for the other
unit, and if it's defined in the filesystem via .wants/ or
.requires/, you can override it by masking it in the filesystem.
Only in the end will all remaining dependencies be combined to
make up the entire list of dependencies for that service.
Would you be agreeable to these semantics? If so, I'll hack up a
patch.
Seems quite intuitive to me. Would be great to have this implemented.
Unless I'm mistaken, the only real change is that Wants= will clear
list, just like it does it for ExecStart=. This should be rather
straightforward to implement I guess.
Also links in .wants and .requires can be masked. It's not a huge change,
but I not trivial either -- and this part of the code is notriously had to
get right.
What about Wants-=e.service in dropin? Dropins are processed
after .{wants,requires}.d and has advantage that you can remove also
static dependency from
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote: Am 2015-02-16 14:16, schrieb Lennart Poettering: On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... [...] Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. A more complex example to illustrate the latter: /usr/lib/.../a.service: [Unit] Wants=b.service After=c.service /usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service /usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service /usr/lib/.../f.service [Unit] Before=a.service /etc/.../a.service.d/dont-depend-on-b.conf: [Unit] Wants= /etc/.../a.service.d/not-after-c.conf: [Unit] After= /etc/.../a.service.wants/e.service - /dev/null In the end, the dependnecies should be: Wants=d.service - b.service gets removed via drop-in - e.service gets removed because it's masked - but d.service stays, because it was never defined in the unit file, so a drop-in doesn't override it, only the mask does After=f.service - c.service gets removed via drop-in - f.service is not declared in the original unit file but rather in f.service as a Before= dependency, so you'd have to override that to make this go into effect The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Would you be agreeable to these semantics? If so, I'll hack up a patch. Seems quite intuitive to me. Would be great to have this implemented. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Another attempt: Making dependencies properly overridable
Am 2015-02-16 14:16, schrieb Lennart Poettering: On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... [...] Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. A more complex example to illustrate the latter: /usr/lib/.../a.service: [Unit] Wants=b.service After=c.service /usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service /usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service /usr/lib/.../f.service [Unit] Before=a.service /etc/.../a.service.d/dont-depend-on-b.conf: [Unit] Wants= /etc/.../a.service.d/not-after-c.conf: [Unit] After= /etc/.../a.service.wants/e.service - /dev/null In the end, the dependnecies should be: Wants=d.service - b.service gets removed via drop-in - e.service gets removed because it's masked - but d.service stays, because it was never defined in the unit file, so a drop-in doesn't override it, only the mask does After=f.service - c.service gets removed via drop-in - f.service is not declared in the original unit file but rather in f.service as a Before= dependency, so you'd have to override that to make this go into effect The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Would you be agreeable to these semantics? If so, I'll hack up a patch. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
