SYSTEMD.PRESET(5)

✨ SYSTEMD.PRESET(5) ✨

okay bestie, gather round, because we're talking about systemd.preset — the manual page for service enablement presets 💅 and honestly? it's giving "who gets to be on by default" energy and I'm obsessed.

---

🌸 NAME 🌸

systemd.preset — service enablement presets

---

🎀 SYNOPSIS 🎀

/etc/systemd/system-preset/*.preset
/run/systemd/system-preset/*.preset
/usr/local/lib/systemd/system-preset/*.preset
/usr/lib/systemd/system-preset/*.preset
/etc/systemd/user-preset/*.preset
/run/systemd/user-preset/*.preset
/usr/local/lib/systemd/user-preset/*.preset
/usr/lib/systemd/user-preset/*.preset
/etc/systemd/initrd-preset/*.preset
/run/systemd/initrd-preset/*.preset
/usr/local/lib/systemd/initrd-preset/*.preset
/usr/lib/systemd/initrd-preset/*.preset

like, that's a lot of directories and every single one of them matters, no cap 🫶

---

💖 DESCRIPTION 💖

So preset files are literally how you encode policy — as in, which units get enabled by default and which ones get disabled. The girlies reading them? That's systemctl preset, and it uses all this info to enable or disable a unit for you. Depending on the policy it finds, systemctl preset is basically identical to systemctl enable or systemctl disable. ✨

And who's out here calling it? The post install scriptlets of rpm packages (or other OS package formats, we don't discriminate 💜). They use systemctl preset to enable/disable specific units by default when a package gets installed, enforcing distribution, spin, or administrator preset policy. The whole point is you can choose a certain set of units to enable/disable even before installing the actual package. slay. for more info, go look at systemctl(1).

lowkey important: it is not recommended to ship preset files inside the respective software packages that implement the units. Instead, centralize them in a distribution or spin default policy, which can then be amended by administrator policy — see below bestie 💅

And if no preset files exist at all? Then preset operations will enable all units that are installed by default. If that's not the vibe and you'd rather everything be off, you have to ship a preset file with a single, catchall "disable *" line. (peep example 1 below 👀)

Oh and — when the machine boots for the very first time, systemd(1) will enable/disable all units according to preset policy, similarly to systemctl preset-all. Also check out ConditionFirstBoot= in systemd.unit(5) and "First Boot Semantics" in machine-id(5). 🌈

---

🦋 PRESET FILE FORMAT 🦋

Each preset file contains a list of directives, one per line. Empty lines are ignored, and so are lines whose first non-whitespace character is "#" or ";". Each directive is one of the words "enable", "disable", or "ignore", followed by whitespace and a unit name. That unit name may contain shell-style wildcards. 🎀

For the enable directive for template units, you can specify one or more instance names as a space-separated list after the unit name. In that case, those instances get enabled instead of the instance specified via DefaultInstance= in the unit. iconic.

Presets must refer to the "real" unit file, and not to any aliases. See systemd.unit(5) for a description of unit aliasing. 🫶

Three different directives are understood:

• "enable" — may be used to enable units by default
• "disable" — to disable units by default
• "ignore" — to ignore units and leave existing configuration intact

If multiple lines apply to a unit name, the first matching one takes precedence over all others. periodt.

Each preset file shall be named in the style of <priority>-<policy-name>.preset. Here's the hierarchy tea ☕:

• Files in /etc/ override files with the same name in /usr/lib/ and /run/.
• Files in /run/ override files with the same name in /usr/lib/.
• Packages should install their preset files in /usr/lib/.
• Files in /etc/ are reserved for the local administrator, who may use this logic to override the preset files installed by vendor packages.

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. It is recommended to prefix all filenames with a two-digit number and a dash, to simplify the ordering of the files. 💅

If the administrator wants to disable a preset file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/systemd/system-preset/ bearing the same filename. yes, that's the move 💀

---

🌟 EXAMPLES 🌟

Example 1. Default to off

# /usr/lib/systemd/system-preset/99-default.preset

disable *

This disables all units. Because of the filename prefix "99-", it will be read last and hence can easily be overridden by spin or administrator preset policy. no cap.

Example 2. Enable multiple template instances

# /usr/lib/systemd/system-preset/80-dirsrv.preset

enable dirsrv@.service foo bar baz

This enables all three of dirsrv@foo.service, dirsrv@bar.service and dirsrv@baz.service. three for the price of one, we love to see it 🎀

Example 3. A GNOME spin

# /usr/lib/systemd/system-preset/50-gnome.preset

enable gdm.service
enable colord.service
enable accounts-daemon.service
enable avahi-daemon.*

This enables the three mentioned units, plus all avahi-daemon regardless of which unit type. A file like this could be useful for inclusion in a GNOME spin of a distribution. It will ensure that the units necessary for GNOME are properly enabled as they are installed. It leaves all other units untouched, and subject to other (later) preset files — for example like the one from the first example above. 🌸

Example 4. Administrator policy

# /etc/systemd/system-preset/00-lennart.preset

enable httpd.service
enable sshd.service
enable postfix.service
disable *

This enables three specific services and disables all others. This is useful for administrators to specifically select the units to enable, and disable all others. Due to the filename prefix "00-" it will be read early and override all other preset policy files. main character energy fr fr 👑

---

💜 MOTIVATION FOR THE PRESET LOGIC 💜

Different distributions have different policies on which services shall be enabled by default when the package they're shipped in gets installed. Let's compare:

• On Fedora all services stay off by default, so that installing a package will not cause a service to be enabled (with some exceptions).
• On Debian all services are immediately enabled by default, so that installing a package will cause its services to be enabled right-away.

Even within a single distribution, different spins (flavours, remixes, whatever you might want to call them) also have different policies on what services to enable and what services to leave off. For example, Fedora Workstation will enable gdm as display manager by default, while the Fedora KDE spin will enable sddm instead. see, different vibes entirely ✨

Different sites might also have different policies about what to turn on by default and what to turn off. For example, one administrator would prefer to enforce the policy of "sshd should be always on, but everything else off", while another one might say "snmpd always on, and for everything else use the distribution policy defaults".

Traditionally, policy about which services shall be enabled was implemented in each package individually. This made it cumbersome to implement different policies per spin or per site, or to create software packages that do the right thing on more than one distribution. The enablement mechanism was also encoding the enablement policy. 😭 messy.

The preset mechanism allows clean separation of:

• the enablement mechanism (inside the package scriptlets, by invoking systemctl preset), and
• the enablement policy (centralized in the preset files)

...and it lifts the configuration out of individual packages. Preset files may be written for specific distributions, for specific spins or for specific sites, in order to enforce different policies as needed. It is recommended to apply the policy encoded in preset files in package installation scriptlets. 💅

---

🧚 SEE ALSO 🧚

systemd(1), systemctl(1), systemd-delta(1)

daemon(7) has a discussion of packaging scriptlets.

Fedora page introducing the use of presets: Features/PackagePresets[1].

---

🍓 NOTES 🍓

1. Features/PackagePresets https://fedoraproject.org/wiki/Features/PackagePresets

---

and that's the whole page bestie!! go forth and preset responsibly 🦋

mwah 💖 this was brought to you by systemd 262.1 and the page SYSTEMD.PRESET(5) — catch you in the next manpage, ily!! ✨🎀