Lennart Poettering wrote:

> On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote:
> 
>> Unfortunately one cannot specify ConsistsOf in a unit file, which
>> is a really annoying limitation.
> 
> That limitation exists for a reason: systemd loads unit files lazily:
> only units that are referenced by some other unit are loaded.

By reference you mean a reference that causes a unit file to be loaded
like Wants? I understand that ConsistsOf is not (would not be) such
a reference, but TBH I don't quite understand why.

Is this something to do with "positive" and "inverse" dependencies and
PartOf being already a positive one? (I'm staring at the UnitDependency
enum).

I kinda understand it was made this way mainly or even only with
instance units in mind. Correct?

> Thus, just sticking a unit file somewhere, and writing ConsistsOf=
> into it, would generally not work, since the dep would never be
> considered unless you also have a dep from something else on it. To
> avoid this confusion we simply don't support it at all.

What I've actually tried after learning about PartOf some time ago:

# foo.target
[Unit]
Wants=a.service b.service c.service
ConsistsOf=a.service b.service c.service

so I can start/stop/restart a bunch of services with systemctl. Both
lists in one place, so it would be hard to forget about something while
making changes. Single file to edit - neat. Just perfect - that's what
I thought until a moment later.

> (Only way to make this work would be by allowing ConsistsOf= deps via
> .consistsof subdirs with symlinks like we support it for .wants, and
> then have ConsistsOf= in the [Install] section, if you follow what I
> mean).

.consistsof and [Install]/PartOf would sound reasonable, just
like .wants and [Install]/WantedBy. [Install]/ConsistsOf seems wrong.

But how will this solve anything? Is .wants different from Wants?

-- 
kjk
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to