Arch and systemd presets

ectospasm · 2024-02-18 23:25:31

Toolybird referred me here when I opened GitLab systemd issue #24 because systemd-timesyncd.service is not enabled by default, despite its preset being enabled. I found this really confusing, since anything with an enabled preset should be enabled by default, or so I thought.

My original problem, systemd-timesyncd not running by default, is easily overcome by sudo systemctl enable --now systemd-timesyncd, which is easy to miss following the installation guide (you have to click the link to the Systemd-timesyncd wiki article, and follow the instruction to start/enable it). Because of the preset, however, I felt this shouldn't be necessary, and was shocked it wasn't already running on my new laptop.

I ultimately determined that systemctl preset-all is not run in the post_install() function of systemd.install, and this appears to be a design decision, if not an oversight. systemd ships with /usr/lib/systemd/system-preset/90-systemd.preset, which among other things has the following line:

enable systemd-timesyncd.service

The systemd PKGBUILD merely uses systemctl to enable three units in post_install(), rather than using presets. The 90-systemd.preset is merely ignored by Arch, since systemctl preset-all isn't run. This may be better to set up in say an 80-archlinux.preset where these three units can be enabled, and the 99-default.preset, can be kept as is:

disable *

At least anyone depending on the output of systemctl status <unit> can at least see if a preset enables any given service.

Lone_Wolf · 2024-02-19 11:52:00

For clarity :

A. Is your issue that 90-systemd.preset is overruled by 99-systemd.preset while systemd.preset manpage claims earlier lexicographic entries have priority and overrules later entries ?

B. you feel archlinux should use upstream presets instead of the small subset that's now enabled ?

C . None of the Above.

A,B or C ?

Last edited by Lone_Wolf (2024-02-19 11:52:57)

ectospasm · 2024-02-19 15:26:08

Lone_Wolf wrote:

For clarity :
A. Is your issue that 90-systemd.preset is overruled by 99-systemd.preset while systemd.preset manpage claims earlier lexicographic entries have priority and overrules later entries ?

Yes, this is the issue. Arch seems to ignore presets in systemd, and this didn't meet my expectation.

Lone_Wolf wrote:

B. you feel archlinux should use upstream presets instead of the small subset that's now enabled ?

Not necessarily. I don't think we should change any functionality within Arch. The idea would be for Arch to define its own preset file. The more I think about it, the more I'm thinking of forking the systemd PKGBUILD/systemd.install scripts.

My idea is to revamp, so just the three units that get enabled by default remain enabled via preset, and everything else is disabled. That way the default services show preset: enabled, and everything else shows preset: disabled properly. I believe that is the intention from upstream, and Arch doesn't do it that way.

I'm thinking of adding/generating say an 80-archlinux.preset file, with the following contents:

enable getty@tty1.service
enable remote-fs.target
enable systemd-userdbd.socket
disable *

Then, where we now call systemctl enable to enable these, we can call systemctl preset-all and the same end will be achieved, only systemd will show these enabled by preset and everything else would be disabled via preset. Without disable * in this file, the upstream services in 90-systemd.preset would be enabled, which would definitely be different than it is today.

We could keep 99-default.preset, but it would be overridden by this proposed preset file.

Lone_Wolf wrote:

C . None of the Above.
A,B or C ?

So A, and B with a caveat: Arch shouldn't follow the upstream 90-systemd.preset, but checking the status of any service would show preset: disabled for any unit that isn't enabled by default. Right now, that piece isn't the case since there isn't a preset disabling several units, including systemd-timesyncd.service, and I found this royally confusing.

The idea is for Arch to use presets to enable what it wants to enable by default, and disable anything that isn't supposed to be running by default (which is pretty much everything but those three units above).

merlock · 2024-02-19 16:16:59

I'd want Arch to "stay the current course".

ectospasm wrote:

My original problem, systemd-timesyncd not running by default, is easily overcome by sudo systemctl enable --now systemd-timesyncd, which is easy to miss following the installation guide (you have to click the link to the Systemd-timesyncd wiki article, and follow the instruction to start/enable it). Because of the preset, however, I felt this shouldn't be necessary, and was shocked it wasn't already running on my new laptop.

But, when I installed Arch, I went with ntpd. Why would *I* want systemd-timesyncd enabled by default?

It seems to me that you (@ectospasm) seem to be focusing on a display issue.

ectospasm · 2024-02-19 17:23:40

merlock wrote:

I'd want Arch to "stay the current course".
ectospasm wrote:
...
But, when I installed Arch, I went with ntpd. Why would *I* want systemd-timesyncd enabled by default?
It seems to me that you (@ectospasm) seem to be focusing on a display issue.

Actually, staying the course is exactly what I'm proposing, with the added benefit that only what Arch enables by default shows preset: enabled; all else will show preset: disabled, including systemd-timesyncd (it was merely this service that led me to the actual problem I'm mentioning in this topic). What I'm proposing is what systemd upstream intends with presets, and Arch isn't using them properly.

Because Arch doesn't really apply the presets at all, I was very confused when systemd-timesyncd was NOT enabled by default, because right now it shows Loaded: ...preset: enabled due to it being enabled in 90-systemd.preset. If it's not intended to be enabled by default, that's all well and good and its actual status doesn't need to change; but the preset value should show disabled in that case. That it's the opposite was very confusing for me, and likely others that would depend on that being accurate.

Anything enabled by preset should be enabled by default, per the current design of systemd. Likewise, anything disabled in a preset should remain disabled until it is explicitly enabled by the system administrator. Upstream actively encourages distribution providers to install their own presets; all I'm proposing is that Arch follow that, and have their own preset which enables the three units they enable with systemctl enable today (in systemd.install/post_install()), and disable everything else. Instead, do it with a proper preset which gets loaded by systemctl preset-all, my 80-archlinux.preset proposal does just that. Users would never notice the difference if my proposal gets accepted unless they look at the preset flag in the systemctl status output.

systemctl preset-all was added to systemd in version 215, and systemctl preset was added in version 238 (according to systemctl(1)). My guess is this portion of the PKGBUILD and systemd.install scripts predates these versions, and it hasn't been updated to reflect available functionality.

Last edited by ectospasm (2024-02-19 17:51:41)

ectospasm · 2024-02-19 17:35:45

Here's the commit I'm proposing, but I wasn't going to issue the MR until we've had more discussion:

https://gitlab.archlinux.org/ectospasm/ … t_id=41007

I haven't tested this, and this comment on the original code confuses me:

# enable some services by default, but don't track them

I'm not sure what is meant by "but don't track them."

EDIT: It looks like I shouldn't modify the main branch. So I'll need to use a different branch, but this at least demonstrates my proposal, how I'd fix it.

EDIT2: URL updated with proper, non-main branch

Last edited by ectospasm (2024-02-19 18:40:21)

moon_moon · 2024-02-19 19:37:15

Hello, I'm using an archISO custom for personal use and I agree with ectospasm.
I was just struggling with this part for the same reasons and by chance I came across this discussion
Now I understand better why I can't do it, for example:

${airootfs}/etc/systemd/system-preset/00-zzlast.preset
enable systemd-timesyncd.service
enable systemd-resolved.service
disable systemd-networkd-service
disable systemd-networkd-wait-online.service
disable systemd-network-generator.service
disable systemd-homed.service
disable systemd-boot-update.service
disable systemd-firstboot"

As archISO does, you can eventually bypass the presets by creating certain symlink in airootfs, for example :

ln -s /usr/lib/systemd/system/NetworkManager.service "${airootfs}/etc/systemd/system/multi-user.target.wants/NetworkManager.service"

But without the systemd preset there is no clean way to pre-disable services too.
The only way I've found to do this in the meantime is to create a "oneshoot" service that will finish the configuration on the first boot with a bash script, but that's crappy.

swsnr · 2024-02-20 10:00:16

The order of presets and how different preset files interact is clearly documented in systemd.preset(5), see https://man.archlinux.org/man/systemd.p … ILE_FORMAT

All preset files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same unit name, the entry in the file with the lexicographically earliest name will be applied.

Hence, "99-default.preset" applies to all services which are not defined in any earlier preset file. This specifically implies that "systemctl preset-all" will effectively disable all services the user has manually enabled with "systemctl enable".

That's likely the reason why systemd doesn't use "systemctl preset-all" in its postinstall script: It'd disable all services the user has explicitly enabled, unless the user took care to update their own preset file accordingly. Given that the wiki routinely recommends to use "systemctl enable" this would be very surprising behaviour with somewhat serious implications for backwards compatibility. The PKGBUILD could use "systemctl preset-all --preset-mode=enable" in its postinstall script, but that'd probably still be surprising, given that the default systemd preset enables a couple of services not everyone needs, such as timesyncd.

But nothing stops you to use your own presets for your own service management and run "systemctl preset-all" routinely, so just go ahead and use presets if you like.

Edit: Wrt to "Anything enabled by preset should be enabled by default, per the current design of systemd.", what's your source for this presumed systemd design? I don't think "system.preset(5)" supports this claim, and much less what you make of it, namely to routinely run "systemctl preset-all" in the postinstall function of the systemd PKGBUILD.

"system.preset(5)" explicitly recommends against shipping preset files along with software packages, and instead suggests to "centralize them in a distribution or spin default policy"; a suggestion which doesn't apply to Arch as it does not have a distribution or spin default policy (see e.g. "It does not add automation features such as enabling a service simply because the package was installed." at https://wiki.archlinux.org/title/Arch_Linux#Simplicity). As such, presets arguably don't apply to Arch Linux at all, as Arch Linux intentionally does not support their use case in terms of a default distribution policy.

Furthermore, systemd itself never applies presets automatically after the very first boot, suggesting that presets are only intended for the first initial configuration of a system, and somewhat more targeted at immutable or appliance-like systems instead of mutable distributions such as Arch Linux.

Last edited by swsnr (2024-02-20 10:26:03)

ectospasm · 2024-02-25 21:34:54

I'm trying to test my proposed commit in a virtual machine; I'm not quite there yet. The commit I linked above is incorrect;
not all of the units are enabled upon first boot. Kind of hard to log into a new Arch system if getty@tty1.service isn't running.

Life got in the way since I last posted, but I did make progress before I left it alone last week.

ectospasm · 2024-02-26 01:43:28

swsnr wrote:

The order of presets and how different preset files interact is clearly documented in systemd.preset(5), see https://man.archlinux.org/man/systemd.p … ILE_FORMAT
All preset files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same unit name, the entry in the file with the lexicographically earliest name will be applied.
Hence, "99-default.preset" applies to all services which are not defined in any earlier preset file. This specifically implies that "systemctl preset-all" will effectively disable all services the user has manually enabled with "systemctl enable".
That's likely the reason why systemd doesn't use "systemctl preset-all" in its postinstall script: It'd disable all services the user has explicitly enabled, unless the user took care to update their own preset file accordingly. Given that the wiki routinely recommends to use "systemctl enable" this would be very surprising behaviour with somewhat serious implications for backwards compatibility. The PKGBUILD could use "systemctl preset-all --preset-mode=enable" in its postinstall script, but that'd probably still be surprising, given that the default systemd preset enables a couple of services not everyone needs, such as timesyncd.
But nothing stops you to use your own presets for your own service management and run "systemctl preset-all" routinely, so just go ahead and use presets if you like.
Edit: Wrt to "Anything enabled by preset should be enabled by default, per the current design of systemd.", what's your source for this presumed systemd design? I don't think "system.preset(5)" supports this claim, and much less what you make of it, namely to routinely run "systemctl preset-all" in the postinstall function of the systemd PKGBUILD.
"system.preset(5)" explicitly recommends against shipping preset files along with software packages, and instead suggests to "centralize them in a distribution or spin default policy"; a suggestion which doesn't apply to Arch as it does not have a distribution or spin default policy (see e.g. "It does not add automation features such as enabling a service simply because the package was installed." at https://wiki.archlinux.org/title/Arch_Linux#Simplicity). As such, presets arguably don't apply to Arch Linux at all, as Arch Linux intentionally does not support their use case in terms of a default distribution policy.
Furthermore, systemd itself never applies presets automatically after the very first boot, suggesting that presets are only intended for the first initial configuration of a system, and somewhat more targeted at immutable or appliance-like systems instead of mutable distributions such as Arch Linux.

Arch ships with 90-systemd.preset from upstream, and systemctl preset-all doesn't get called currently, as you pointed out. But because this upstream file exists, files that are enabled by preset in any shipped preset file (or any preset installed by the system administrator), systemctl status <unit> (such as systemctl status systemd-timesyncd) will show that it is enabled by preset, which leads at least two people on this thread (including myself) to think they should be enabled by default, even though it's disabled by default in Arch. systemctl status <unit> essentially compiles all presets, sorts them lexicographically, and ensures the ones enabled by the presets earlier alphabetically/lexicographically apply before later ones. Currently, anything enabled by preset isn't enabled by default in Arch; I'm trying to change this.

My proposal is to define 80-archlinux.preset with just the three units that Arch already enables by default, so a system administrator reviewing units with systemctl status <unit> sees Loaded: ...enabled preset: enabled knows they were enabled by default. This way, no unit with preset: enabled will be disabled by default (which is the status quo as of right now). My proposal does make 99-default.preset superfluous, but it doesn't really affect anything by still being there.

And when a system administrator installs base when they run pacstrap, it includes systemd, and all the files in the package (including my new 80-archlinux.preset) get copied into the mount point. Also, since this constitutes a new installation of systemd, the post_install() function (part of systemd.install) gets called; as I'm proposing instead of enabling individual units (which is what systemd does now), it runs systemctl preset-all, achieving the same end but fixing the problem with units having preset: enabled but still being disabled by default. This is well before the system administrator enters the Arch chroot, and enables any services manually; by that point systemctl preset-all has already been run, and this does not conflict with the usual expectations of Arch users.

I'd like to stress: this does not change anything with Arch systems installed already; except the preset field of the Loaded line of systemctl status <unit> will only show enabled for the three units that are enabled by default. If this makes it into core, while 80-archlinux.preset will be installed, I do not recommend users run systemctl preset-all (unless they set up their own preset file according to the manual), as that would likely disable all the services they've already manually enabled.

Last edited by ectospasm (2024-02-26 02:17:57)

swsnr · 2024-02-26 18:02:33

I understand, but I believe Arch's standpoint would be that your confusion is your problem. I think Arch generally expects you to understand the software you're using which includes systemd, i.e. you should know the difference between "preset: enabled" and "enabled" in "systemctl status". So your confusion wouldn't probably not be considered as an argument in favour of your proposed change.

And I think that you probably can't make a compelling argument that systemd is supposed to be used with presets here, because as said I don't think that's evident from systemd's documentation.

However, personally I think it's a interesting proposal, and worth discussing with the package maintainer. But in your argument for the change you'd best focus on the actual merits of presets here, i.e. more transparency for the administrator as the set of enabled services is actually written down in a file, and more liberty wrt to configuration, as you can stub out the preset before `pacstrap` if you'd like to use a different set of services (e.g. disable getty for whatever reason), and not argue that the current state of affairs is confusing.

And–given that you stressed this point specifically–do note that this does affect existing Arch installations in case they do make use of presets. In these installations the administrator probably applies "systemd preset-all" routinely, and would definitely notice if the current default presets would change. I'd affect my installations for sure, because I do use presets to manage enabled services, and I'd definitely notice if "90-systemd.preset" would not longer apply.

That's a point you'd need to consider if you take your proposal to the systemd packaging repo.

ectospasm · 2024-02-27 03:00:24

I will suggest the MR, and the maintainers are welcome to accept or reject it. The whole purpose of the presets is for distribution providers, and system administrators to define their own presets. Looking at the commit history, this portion of the systemd package predates the systemd preset-all functionality, or at least it was quite new when the three units were finalized back in 2014 or so; I'm just suggesting that Arch adopt how upstream is now intending this to work. Every other distribution based on systemd that I've used uses these presets to define which services are enabled by default. I think Debian and Ubuntu likely have something like enable * in their presets, so every service installed gets enabled and started by default; I'm not suggesting that for Arch at all, just to make it follow presets for the three units (one service, one target, and one socket) enabled by default, and let the preset field reflect that. It's very bizarre to see something enabled by preset, but disabled by default. Obviously if the system administrator defines their own preset in /etc/systemd/system, it would supersede any presets installed by default; Levente even uses an example of that in the manual page for systemd-preset. But in that case the administrator should know what they're doing.

But for now I'm running into a problem with pkgctl build systemd (for a clean chroot) apparently pausing when running some scripts when I try to build the updated package. It had been completing last week, but something has changed and I'm not sure what. I haven't updated my laptop since I'd been trying to get this working since yesterday. I did update, and I'm about to reboot. I didn't see a systemd update in the upgrade, but we'll see.

swsnr · 2024-02-27 07:11:51

Perhaps open an issue first to figure out whether the systemd package maintainer would even be interested in using presets here?

Your post reads as if you're already spending a lot of time on this, and that might be wasted if the package maintainer decides against this...

Head_on_a_Stick · 2024-02-27 21:16:07

ectospasm wrote:

I think Debian and Ubuntu likely have something like enable * in their presets, so every service installed gets enabled and started by default

Debian uses dh_installsystemd(1) to ensure unit files are enabled during package installation. It ships no distribution-specific preset file, unlike Arch.

ectospasm · 2024-03-10 12:15:00

swsnr wrote:

Perhaps open an issue first to figure out whether the systemd package maintainer would even be interested in using presets here?
Your post reads as if you're already spending a lot of time on this, and that might be wasted if the package maintainer decides against this...

If you read my initial post in this topic, I did open an issue on GitLab. The maintainer or bug wrangler referred me here.

And this is a hobby for me, I like tinkering with this stuff. In general, an opportunity to learn more about Linux, specifically Arch, is a valuable exercise in itself, even if the maintainer ultimately rejects my MR.

ectospasm · 2024-03-10 12:17:12

Head_on_a_Stick wrote:

ectospasm wrote:
I think Debian and Ubuntu likely have something like enable * in their presets, so every service installed gets enabled and started by default
Debian uses dh_installsystemd(1) to ensure unit files are enabled during package installation. It ships no distribution-specific preset file, unlike Arch.

Yet another bespoke tool in Debian (one of the reasons I don't use Debian anymore), that likely predates systemd having presets.

ectospasm · 2024-03-16 14:42:22

I finally got my systemd PKGBUILD changes to work in a VM; !14 is my MR. As I tried to mention, this does not change anything except how the default systemd units in Arch linux are enabled. Any existing installation which installs this version will get the 80-archlinux.preset file (so preset: enabled will only show for the default units), but nothing should change otherwise. systemctl preset-all only gets called upon new installation, so it should not break existing installations.

swsnr · 2024-03-16 15:44:09

As said before, your proposal would definitely change things for people already using presets and relying on 90-systemd.preset for the core systemd infrastructure. Your change effectively renders 90-systemd.preset unreachable and will thus break any installation which relies upon it.

ectospasm · 2024-03-16 19:31:52

swsnr wrote:

As said before, your proposal would definitely change things for people already using presets and relying on 90-systemd.preset for the core systemd infrastructure. Your change effectively renders 90-systemd.preset unreachable and will thus break any installation which relies upon it.

How does one rely on 90-systemd.preset if none of its enabled units are enabled by default in Arch? How does one get them to be enabled by default? I guess they could execute systemctl preset-all manually upon installation, but where in the Install Guide is this suggested? How prevalent is this, given Arch doesn't properly use presets to begin with?

And this wouldn't change anything exept the preset: enabled flag on enabled units (but disabled by default in Arch); the system administrator would need to run systemctl preset-all after systemd is upgraded with this change for it to be a problem. Why one would have a pacman hook to do this is beyond me; plenty of desired services wouldn't normally be enabled by preset.

A notice could be provided if this does get accepted and moved into core; any user relying on 90-systemd.preset would be better suited to place their desired preset in /etc/systemd/system-preset/, in a lexicographically higher priority than 80-archlinux.preset. I believe this is the intention of upstream, again by my reading of the manual page.

seth · 2024-03-16 21:50:50

Disclaimer: I've only peripherally followed this so there could be a misassumption on my side.

Users & admins should™ configure presets in /etc only anyway, but I think swsnr's point is that those local configs will probably only augment 90-systemd.preset, not replace it.
So if the latter is no longer reached, their next preset-all call will disable a lot of critical infrastructure?

If that's indeed the case, any such change would have to come w/ an explicit announcement and warning.
Speculations about prevalence are moot - your risking to badly break systems for essentially just some optics.

Arch Linux

#1 2024-02-18 23:25:31

Arch and systemd presets

#2 2024-02-19 11:52:00

Re: Arch and systemd presets

#3 2024-02-19 15:26:08

Re: Arch and systemd presets

#4 2024-02-19 16:16:59

Re: Arch and systemd presets

#5 2024-02-19 17:23:40

Re: Arch and systemd presets

#6 2024-02-19 17:35:45

Re: Arch and systemd presets

#7 2024-02-19 19:37:15

Re: Arch and systemd presets

#8 2024-02-20 10:00:16

Re: Arch and systemd presets

#9 2024-02-25 21:34:54

Re: Arch and systemd presets

#10 2024-02-26 01:43:28

Re: Arch and systemd presets

#11 2024-02-26 18:02:33

Re: Arch and systemd presets

#12 2024-02-27 03:00:24

Re: Arch and systemd presets

#13 2024-02-27 07:11:51

Re: Arch and systemd presets

#14 2024-02-27 21:16:07

Re: Arch and systemd presets

#15 2024-03-10 12:15:00

Re: Arch and systemd presets

#16 2024-03-10 12:17:12

Re: Arch and systemd presets

#17 2024-03-16 14:42:22

Re: Arch and systemd presets

#18 2024-03-16 15:44:09

Re: Arch and systemd presets

#19 2024-03-16 19:31:52

Re: Arch and systemd presets

#20 2024-03-16 21:50:50

Re: Arch and systemd presets

Board footer