Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
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@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@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@.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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Wednesday 17 of September 2014 11:50:08 Zbigniew Jędrzejewski-Szmek wrote: On Wed, Sep 17, 2014 at 08:52:00AM +0200, Pavel Raiskup wrote: 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). Sorry, but the .include mechanism is deprecated (and almost unused nowadays) Note that the thing that .include changed its semantics due to drop-in feature is not really proper deprecation. Nor any documentation, warnings about its usage, etc. and we are not going to work on changing the semantics of something that we don't want people to use anyway. TBH, I'm not sure where I asked you to work on something, just wanted to do some high-level discussion. But it does not matter. The question was left behind: What would get broken if the .include haven't this unexpected side-efect? Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Wednesday 17 of September 2014 20:06:50 Andrei Borzenkov wrote: В Wed, 17 Sep 2014 13:40:11 +0200 Pavel Raiskup prais...@redhat.com пишет: On Wednesday 17 of September 2014 11:50:08 Zbigniew Jędrzejewski-Szmek wrote: On Wed, Sep 17, 2014 at 08:52:00AM +0200, Pavel Raiskup wrote: 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). Sorry, but the .include mechanism is deprecated (and almost unused nowadays) Note that the thing that .include changed its semantics due to drop-in feature is not really proper deprecation. Nor any documentation, warnings about its usage, etc. I reread your original post and I still fail to see what has changed. IIRC .include file always meant literally inline content of file in place of .include line. This is exactly what still happens now. Do you have pointers to old documentation that stated something different? Say that A.service .includes B.service. Because B.service was correctly inlined before, A.service was able to re-define results of .include. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Wednesday 17 of September 2014 20:44:38 Andrei Borzenkov wrote: В Wed, 17 Sep 2014 18:29:35 +0200 Pavel Raiskup prais...@redhat.com пишет: On Wednesday 17 of September 2014 20:06:50 Andrei Borzenkov wrote: В Wed, 17 Sep 2014 13:40:11 +0200 Pavel Raiskup prais...@redhat.com пишет: On Wednesday 17 of September 2014 11:50:08 Zbigniew Jędrzejewski-Szmek wrote: On Wed, Sep 17, 2014 at 08:52:00AM +0200, Pavel Raiskup wrote: 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). Sorry, but the .include mechanism is deprecated (and almost unused nowadays) Note that the thing that .include changed its semantics due to drop-in feature is not really proper deprecation. Nor any documentation, warnings about its usage, etc. I reread your original post and I still fail to see what has changed. IIRC .include file always meant literally inline content of file in place of .include line. This is exactly what still happens now. Do you have pointers to old documentation that stated something different? Say that A.service .includes B.service. Because B.service was correctly inlined before, A.service was able to re-define results of .include. *file* B.service is still correctly inlined. You are unable to re-define the effect of .include in the file A.service anymore. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Wednesday 17 of September 2014 20:58:02 Andrei Borzenkov wrote: Huh? Argh! .. and finally, thanks a lot for your exmaple. I iterated into the sitation that this is not about .include. Probably due to some false premise or testing result, I lived in false feeling that the .include is _the trigger_ of loading the /usr/lib/ drop-ins. But it is independent on .include. And your example works because I mistakenly pointed you tu use A.service and B.service (not 2xA). Thanks again, Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
Hi, consider the situation that admin has /etc/systemd/system/a.service, which includes via .include the /usr/lib/systemd/system/a.service. Then in our case there exists also packaged /usr/lib/systemd/system/a.service.d/ with existing drop-in. In this case - the setup from /etc/ is beaten by drop-in files from /usr/lib. Reproducer is in Red Hat Bugzilla [1]. I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. The use-case to make it complete: I would like to have the .include supported just for compatibility with older admin's settings. Then I would like to install two service files 'a.service' and 'a@.service', both hardlinked (ideally). The 'a.service' would diverge from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf settings. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1141824 Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
This is reply to both Tomasz and Zbigniew, thanks for reactions! On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: On Tue, Sep 16, 2014 at 03:16:12PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote: I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. This should not be a revert. Just make it properly defined? At least not without a very good reason which would make it worth to upset existing users. Oh, yeah - that would not be nice; but the way how it is done now does not seem to be logical (and breaks otherwise nice possibilities) - so I would call it good reason (unless somebody hits me with good reason :)). I'm just not sure who we could upset - do you think there is anybody relying on the current approach? What would be the use case? On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? Look at the initial email: | Then I would like to install two service files 'a.service' and | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge | from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf | settings. To make it more clear - such service 'a' would have its defaults preconfigured in package; run by `systemctl start a` and configurable 'a@whatever.service'. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tuesday 16 of September 2014 16:41:49 Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 04:35:50PM +0200, Pavel Raiskup wrote: This should not be a revert. Just make it properly defined? It was already properly defined, maybe just not explicitly documented for this case. And yes, this is used: Well, yeah .. :( ok, probably I'm doing something wrong. 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? At least not without a very good reason which would make it worth to upset existing users. Oh, yeah - that would not be nice; but the way how it is done now does not seem to be logical (and breaks otherwise nice possibilities) - so I would call it good reason (unless somebody hits me with good reason :)). I'm just not sure who we could upset - do you think there is anybody relying on the current approach? What would be the use case? On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? Look at the initial email: | Then I would like to install two service files 'a.service' and | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge | from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf | settings. To make it more clear - such service 'a' would have its defaults preconfigured in package; run by `systemctl start a` and configurable 'a@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@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. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tuesday 16 of September 2014 16:42:32 Jóhann B. Guðmundsson wrote: On 09/16/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote: This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. At least not without a very good reason which would make it worth to upset existing users. The problem which was pretty obvious was going to happen when dropins got added and now is causing confusion and even breakage No confusion on my site, I believe. Nor brakage - only avoiding future breakages. I'm just thinking about doing something better than it is done now, tbh. To not confuse you, I am just (a) trying to get rid of .include statement we supported so far and (b) start using drop-ins, but (c) stay compatible with .include as users are already using that. And as (d) I try to incorporate the nice additional @ unit syntax the cleanest way :). And I try to be constructive - so letting you know. ( think mix match of combinations of ways to overwrite ) is that we need to reduce the means you can overwrite existing unit files to one and deprecate the other ones. Deprecation is fine, though .. Bottom line we should only have one way to do things to keep things simple not three not five not fifty. .. that sounds like something against InterfaceStabilityPromise in this context. And it is definitely not something any of us wants. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
