[systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
Pavel Raiskup
praiskup at redhat.com
Tue Sep 16 23:52:00 PDT 2014
On Wednesday 17 of September 2014 01:33:02 Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Sep 16, 2014 at 05:07:06PM +0200, Pavel Raiskup wrote:
> > > for example
> > > tmpfiles.d/systemd.conf and tmpfiles.d/systemd-nologin.conf are split
> > > exactly for the purpose of making it easier to override separately. The
> > > case of unit files is slightly different, but we really want to have the
> > > same semantics for all configuration file overrides in systemd.
> >
> > Could you please be more specific? You mean that the /usr/lib
> > configuration should have bigger priority than /etc?
>
> There are two independent rules: one is that files with the same name
> override each other (and /etc has higher priority than /usr/lib), and
> second that dropins have higher priority than the "basic" configuration
> files.
>
> So to answer your question directly: no, /usr/lib configuration
> has lower priority, but it might still be visible if not override by
> a file with the same name in /etc or /run.
Thanks, I agree, and yet another rule on top of that -- the /usr/lib
dropins _are ignored_ if /etc service overriding the one in /usr/lib
exists [1] which seems like it is expected (and I appreciate that
behavior).
--
The mission statement: IMO the .include statement changes semantics of
drop-ins; Either (a) processing .include should ignore drop-ins relevant
to includED file, or (b) it should firstly perform "complete include work
together with drop-ins" and then continue with remaining part of service
file _calling_ .include. That way it could be called intuitive (so the
include would similar to "include" from other languages).
I'm not aware of the tmpfiles.d/* problem you mentioned and for that
reason I do not know what can be broken if (a) or (b) was used. Could you
help me with that? As far as I am aware, it should not hurt this
particular case.
Well, I agree and sorry, I should use-the-source .. asap.
> > > > To make it more clear - such service 'a' would have its
> > > > defaults preconfigured in package; run by `systemctl start a` and
> > > > configurable 'a at whatever.service'.
> > >
> > > So we return to Tomasz'es question: why would you split the configuration
> > > into two files?
> >
> > Oh, I probably missed the purpose of the original question, really sorry
> > then. The answer: I don't want to maintain the ugly long (configured)
> > version 'service at DEFAULT.service'. And also it is needed to keep the
> > compatibility with older /etc/*service files. Some users are already
> > "including" our default service.service. This is becoming off-topic
> > the original request, anyway.
>
> I don't think that drop-ins are a solutions for this anyway.
Yes - little bit off topic as I said - dropins are solution for
differentiating otherwise hardlinked 'service at .service' &
'service.service'.
> But the settings from the instance override the settings from the
> template. Isn't this enough?
Yes, as instances do not .include other service files, it is OK, but I
still need to stay compatible with administrator's settings who include
my '/usr/lib/systemd/system/service.service' (and not using drop-ins).
Pavel
More information about the systemd-devel
mailing list