meson: introduce a build option for customizing the install paths of …

[fbuihuu]

…the main config files

This allows distros to install configuration file templates in /usr/lib/systemd for example.

[keszybz]

The patch doesn't contain much justification, so here is my understanding of why this is useful:

Currently we install "empty" config files in /etc/systemd/. They serve two purposes:

• the file contains commented-out values that show the default settings
• it is easier to edit the right file if it is already there, the user doesn't have to type in the path correctly, and the basic file structure is already in place so it's easier to edit.

Things that have happened since this approach was put in place:

• we support loading of the main config file from /usr and /usr/local, in addition to /etc and /run (or maybe this way always true, maybe we just spruced up the docs), so the actual location of the config file varies.
• we started supporting drop-ins for config files, and drop-ins are the recommended way to create local configuration overrides.
• we have systemd-analyze cat-config
• because of the first two points, systemd-analyze cat-config is much better, because it takes care of finding all the drop-ins and figuring out the precedence. Looking at files manually is still possible of course, but not very convenient.
• we have systemctl edit so the user does not have to specify any file/drop-in name.
• systemctl edit shows the (commented out) contents of the existing config, so when a user edits an empty drop-in, they get the correct hints about syntax/option names.

The disadvantages of the current approach with "empty" files in /etc:

• we clutter up /etc so it's harder to see what the local configuration actually is.
• if a user edits the file, package updates will not override the file (e.g. systemd.rpm uses %config(noreplace). This means that the "documented defaults" will become stale over time, if the user ever edits the main config file.

Thus, I think that it's reasonable to:

• install the main config file to /usr/lib so that it serves as reference for syntax and option names and default values and is properly updated on package upgrades
• recommend to users to always use drop-ins for configuration and systemd-analyze cat-config to view the documentation.

EDIT: cross out the mention of systemctl edit as discussed below. We haven't implemented that yet for config files.

[keszybz]

With -Dconfigfiledir=/usr/lib/ I see the following in /etc:

• /etc/init.d/README — OK. We should probably stop installing this, but it's a separate topic.
• /etc/X11/xinit/xinitrc.d/50-systemd-user.sh — OK. Added Xorg to Tracking upstream projects that do not support hermetic-usr for configuration uapi-group/specifications#76.

So this patch seems to behave as expected.

[bluca]

The patch doesn't contain much justification, so here is my understanding of why this is useful:

Currently we install "empty" config files in /etc/systemd/. They serve two purposes:

• the file contains commented-out values that show the default settings
• it is easier to edit the right file if it is already there, the user doesn't have to type in the path correctly, and the basic file structure is already in place so it's easier to edit.

Things that have happened since this approach was put in place:

• we support loading of the main config file from /usr and /usr/local, in addition to /etc and /run (or maybe this way always true, maybe we just spruced up the docs), so the actual location of the config file varies.
• we started supporting drop-ins for config files, and drop-ins are the recommended way to create local configuration overrides.
• we have systemd-analyze cat-config
• because of the first two points, systemd-analyze cat-config is much better, because it takes care of finding all the drop-ins and figuring out the precedence. Looking at files manually is still possible of course, but not very convenient.
• we have systemctl edit so the user does not have to specify any file/drop-in name.
• systemctl edit shows the (commented out) contents of the existing config, so when a user edits an empty drop-in, they get the correct hints about syntax/option names.

The disadvantages of the current approach with "empty" files in /etc:

• we clutter up /etc so it's harder to see what the local configuration actually is.
• if a user edits the file, package updates will not override the file (e.g. systemd.rpm uses %config(noreplace). This means that the "documented defaults" will become stale over time, if the user ever edits the main config file.

Thus, I think that it's reasonable to:

• install the main config file to /usr/lib so that it serves as reference for syntax and option names and default values and is properly updated on package upgrades
• recommend to users to always use drop-ins for configuration and systemd-analyze cat-config to view the documentation.

Makes sense to me - @fbuihuu could you please add the above in the commit message so that it's recorded?

[fbuihuu]

The patch doesn't contain much justification, so here is my understanding of why this is useful:

Thanks for writing this up.

Things that have happened since this approach was put in place:

[...]

• we have systemctl edit so the user does not have to specify any file/drop-in name.
• systemctl edit shows the (commented out) contents of the existing config, so when a user edits an empty drop-in, they get the correct hints about syntax/option names.

I'm a bit confused here since AFAIK systemctl edit works with unit files, not config files. But I think a similar command that would work with config files would make a lot sense. Hence systemd-analyze edit-config systemd/system.conf would show the content of the defaults (commented out) and all the hints about syntax/option names.

With such command and maybe a way to show the defaults (systemd-analyze cat-config --defaults ?) we wouldn't need to install the templates in /usr at all since their sole purpose is to document the defaults.

[YHNdnzj]

But I think a similar command that would work with config files would make a lot sense. Hence systemd-analyze edit-config systemd/system.conf would show the content of the defaults (commented out) and all the hints about syntax/option names.

With such command and maybe a way to show the defaults (systemd-analyze cat-config --defaults ?) we wouldn't need to install the templates in /usr at all since their sole purpose is to document the defaults.

Indeed. This seems more graceful to me.

[fbuihuu]

• we started supporting drop-ins for config files, and drop-ins are the recommended way to create local configuration overrides.

Indeed it's the recommended way because (IMU) using drop-ins exclusively is the only way for packages shipped by downstream to safely customize the defaults without risking to override users' customization. That is the reason why we want to get rid of the main config files (even if they're "empty) and use drop-ins exclusively.

[medhefgo]

• install the main config file to /usr/lib so that it serves as reference for syntax and option names and default values and is properly updated on package upgrades

Imho, if it's all commented out anyway (aka, systemd doesn't derive it's defaults from any files but has them built in) it should really go into /usr/share/doc. Other programs do that too for their example confs.

[bluca]

• install the main config file to /usr/lib so that it serves as reference for syntax and option names and default values and is properly updated on package upgrades

Imho, if it's all commented out anyway (aka, systemd doesn't derive it's defaults from any files but has them built in) it should really go into /usr/share/doc. Other programs do that too for their example confs.

Because when we change defaults downstream it's very easy to just patch that file and uncomment the line, and then it will automatically work as expected

[fbuihuu]

Because when we change defaults downstream it's very easy to just patch that file and uncomment the line, and then it will automatically work as expected

until a user creates his own /etc/systemd/xxx.conf (regardless of which setting is overriden).

[medhefgo]

Because when we change defaults downstream it's very easy to just patch that file and uncomment the line, and then it will automatically work as expected

But those are two different things. Downstream ought to have a analog to /usr/etc where they can put their stuff. But that should not be the same as the upstream default config file examples.

In fact, I propose to get rid of these. The file formats aren't some NIH syndrome format like pipewire is using, so you don't need some giant default config dump so that users can get an idea of how it works. And all the options and their possible values and defaults are clearly documented in their respective manpages, which are also linked from the exe manpage that consumes them. These example configs are just some half-assed cargo cult bs that should stop (especially when dropped into /etc). Iff they contain anything important it should probably be moved into their respective manpage.

[keszybz]

• systemctl edit shows the (commented out) contents of the existing config, so when a user edits an empty drop-in, they get the correct hints about syntax/option names.

I'm a bit confused here since AFAIK systemctl edit works with unit files, not config files. But I think a similar command that would work with config files would make a lot sense. Hence systemd-analyze edit-config systemd/system.conf would show the content of the defaults (commented out) and all the hints about syntax/option names.

This was a bit of a mental shortcut. We have systemctl edit, machinectl edit, networkctl edit. You are of course correct that we don't have this for config files, but I think we could add something like this later.

With such command and maybe a way to show the defaults (systemd-analyze cat-config --defaults ?) we wouldn't need to install the templates in /usr at all since their sole purpose is to document the defaults.

I'm not sure. The nice thing about the current approach is that without it works uniformly, without any special functionality. In particular, the distro may provide packaged drop-ins, under /usr/lib/, and those will be automatically and correctly shown. It may also override something in the main config file, and then again, this will be automatically and correctly shown by systemd-analyze cat-config. I don't want to add yet-another verb that would require special support in various places.

[fbuihuu]

I'm not sure. The nice thing about the current approach is that without it works uniformly, without any special functionality.

Given that the templates might be located in different directories (/etc vs /usr) or even not shipped at all, having a uniform way to retrieve the defaults for all cases sounds appealing to me.

We could even extend systemd-analyze so it actually doesn't show the defaults, which is sometimes easier to spot the actual overrides. Something equivalent to:

# systemd-analyze cat-config systemd/system.conf | egrep '^# /(etc|usr)|^[^#]' 
# /usr/lib/systemd/system.conf
[Manager]
# /usr/lib/systemd/system.conf.d/20-defaults-SUSE.conf
[Manager]
DefaultMemoryAccounting=no
# /etc/systemd/system.conf.d/60-local.conf
[Manager]
DefaultMemoryAccounting=yes

[keszybz]

We could even extend systemd-analyze so it actually doesn't show the defaults

See #29553.

[keszybz]

I force-pushed the commit with an updated commit message.

[YHNdnzj]

This would resolve #18420.

[fbuihuu]

This would resolve #18420.

Yes indeed, I wasn't aware that someone already asked for moving the templates in /usr.

[keszybz]

We discussed this today during a live meeting and the conclusion was to merge this. -Dinstall-sysconfdir=false can be used to create an installation without the only-comment files. To make this nicer we can add a meson install tag, but let's do that in a separate pull request since it's just a convenience feature.