[systemd-devel] Another attempt: Making dependencies properly overridable

[Zbigniew Jędrzejewski-Szmek]

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 (mbiebl at 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