[systemd-devel] Unwants

[Dimitri John Ledkov]

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

the logic would be:
bar.service: [Unit] Wants=foo.service
foo.service: [Install]WantedBy=bar
bar.service.wants/foo.service -> ***/foo.service

Add a dependency type "want" from bar -> to foo.

Whilst:
bar.service: [Unit] Wants=!foo.service
foo.service: [Install]WantedBy=!bar
bar.service.wants/foo.service -> /dev/null

Would remove a dependency link from bar -> to foo, if and only if it
already exists.

The ! syntax is for e.g. overriding symlinks via .d/*.conf files or
when unit is copied into a higher level configuration path and edited.

Thus everything is still coalescing, in the order that configuration
directories are transversed, but proposed to be additive and
subtractive in nature.
(and will thus allow adding/removing dependencies at each configuration level)

e.g.
distro ships user level unit that gpg-agent is enabled by default in
the user sessions
global user override by admin sets gnome-keyring to be the default
agent for user sessions (Wants=gnome-keyring-gpg !gpg-agent)
user overrides the admin to make gpg-agent enabled by default back
(Wants=!gnome-keyring-gpg gpg-agent)

where wants are either .d snippets with lines as in brackets or (valid
| dev-null) symlinks in appropriate .wants directories at respective
configuration levels.

-- 
Regards,

Dimitri.

Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.