[systemd-devel] Unwants

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 27, 2015 at 03:50:49PM +0000, Dimitri John Ledkov wrote:
> On 27 January 2015 at 15:18, Christian Seiler <christian at 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