On Fri, 11 Aug 2023, 19:13:05 +0200, Andrei Borzenkov wrote:
On 11.08.2023 19:59, Manfred Hollstein wrote:
Moin,
to be honest, I'm afraid the whole UsrMerge activitiy told us something completely different!
On Fri, 11 Aug 2023, 18:40:44 +0200, Franck Bui wrote:
Hi,
The way the systemd daemons (such as PID1, logind) parse their configuration file is specified in systemd-system.conf(5) man page (section CONFIGURATION DIRECTORIES AND PRECEDENCE).
Basically the daemons parse first their "main" configuration file (e.g /etc/systemd/system.conf for PID1) and then read and apply the optional drop-in files located in the following directories:
/usr/lib/systemd/*.conf.d/ /usr/local/lib/systemd/*.conf.d/ /run/systemd/*.conf.d/ /etc/systemd/*.conf.d/
*If* systemd (PID1) has access to /usr/lib/systemd/system.conf, it *must* use that file - unless there is a file /etc/systemd/system.conf.
During the process to migrate all /{bin,etc,lib}/* files, we were told to leave the file at /usr/* untouched and make our local modifications to the files at /etc/...
Now systemd wants to tell us a different logic :(
It's important to note that drop-in files have higher precedence than the main configuration file. Hence if a package customizes an option by shipping a drop-in file in /usr/lib/systemd/*.conf.d/, it might override the value already set by the user if the same option was customized by the sysadmin in the main configuration.
There were various discussions [1] about addressing this concern but at the end upstream preferred keeping the existing logic. This implies that using the main configuration files is not 100% safe (even if it's been documented since a long time) especially since openSUSE distros relies on drop-in files to tune a few upstream defaults, see systemd-default-settings package to get the list.
To avoid inconvenient divergences with upstream, we'll follow the existing logic but this implies that:
- use of main config files, such as /etc/systemd/{system.conf,logind.conf}, should be avoided and instead customization should be done via drop-in files, such as /etc/systemd/system.conf.d/50-local.conf.
- Some drop-in priority ranges should be defined to make sure that drop-in created by users have always higher precedence over the ones shipped by packages. The priority ranges reserved for users and downstream will be defined and documented in the relevant wiki page.
- at installation, systemd packages will stop installing (empty/template) main configuration files and instead users will find the templates in drop-in directories (such as /etc/systemd/*.conf.d/50-{local,main,xxx}.conf, exact filename to be defined).
- optionally, the packaging stuff will take care of converting existing main configuration files into drop-in files during package update.
If there's no objection with the above, this change will be probably take place during the upgrade to systemd v254 or quickly after.
Again, to be honest, we had a lot of effort and work to teach the various packages to be able to deal with two different configuration directories below /usr and /etc for overriding stuff, now systemd wants to revert that? I strongly vote NO!
NO to what? Doing nothing and leaving it as is will not magically make systemd honor /usr/lib/systemd/system.conf, nor will it stop it from overriding settings from /etc/systemd/system.conf with something from /usr/lib/sytemd/system.conf.d.
That said, I do not think this change will be beneficial short term. Users will continue to edit /etc/systemd/system.conf because they found description on Internet. Having link /etc/systemd/system.conf -> /etc/systemd/system.conf.d/50-main.conf mai mitigate it as long as systemd allows it in the first place.
NO to what?
NO to systemd ignoring the results of the UsrMerge! *They* must accept that there are some standards and code their stuff accordingly! This was an RFC, wasn't it? This is my comment!
Thanks.
Cheers. l8er manfred