[systemd-devel] Unwants

[Christian Seiler]

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. ;-)