[systemd-devel] Unwants

[Dimitri John Ledkov]

On 27 January 2015 at 16:47, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> 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.
>

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.