SYSEXT.CONF(5)

📦

version 262.1 · 7 versions

💖 SYSEXT.CONF(5) 💖

okay so bestie, pull up a chair, because this is the manual page for sysext.conf, confext.conf, sysext.conf.d, and confext.conf.d — aka the configuration files for systemd-sysext. yes we are doing configuration file lore today. it's giving "infrastructure but make it cute". 🎀

✨ NAME ✨

sysext.conf, confext.conf, sysext.conf.d, confext.conf.d — these are the configuration files for systemd-sysext. that's the whole name situation. short, sweet, iconic. 👑

🌸 SYNOPSIS 🌸

here's the lineup of files, and yes you get all of them, no skips:

/etc/systemd/sysext.conf

/etc/systemd/sysext.conf.d/*.conf

/run/systemd/sysext.conf

/run/systemd/sysext.conf.d/*.conf

/usr/lib/systemd/sysext.conf

/usr/lib/systemd/sysext.conf.d/*.conf

/etc/systemd/confext.conf

/etc/systemd/confext.conf.d/*.conf

/run/systemd/confext.conf

/run/systemd/confext.conf.d/*.conf

/usr/lib/systemd/confext.conf

/usr/lib/systemd/confext.conf.d/*.conf

🦋 DESCRIPTION 🦋

these configuration files are the ones calling the shots for systemd-sysext(8) and systemd-confext(8). lowkey they are especially useful when you need to customize the behavior of the respective extension service units. so if you've ever been like "hmm. i wish this extension service unit behaved differently," this is your moment. main character energy. 💅

🌈 CONFIGURATION DIRECTORIES AND PRECEDENCE 🌈

the default configuration gets set during compilation (yes, at build time, not vibes time), so you only need to touch configuration when you genuinely have to deviate from those defaults. no notes.

the main configuration file is loaded from one of the listed directories, in order of priority, and only the first file found is used. the order is:

/etc/systemd/
/run/systemd/
/usr/local/lib/systemd/ [1]
/usr/lib/systemd/

the vendor version of the file contains commented out entries showing the defaults, as a little guide for the administrator. thoughtful of them, honestly. 🫶

local overrides can also be created by making drop-ins, as described below. the main configuration file can also be edited for this purpose (or a copy in /etc/ if it is shipped under /usr/), however using drop-ins for local configuration is recommended over modifications to the main configuration file. read that again, bestie — drop-ins, not main-file edits. it's the move. ✨

🎀 drop-ins, aka the fun part

in addition to the main configuration file, drop-in configuration snippets are read from:

/usr/lib/systemd/*.conf.d/
/usr/local/lib/systemd/*.conf.d/
/etc/systemd/*.conf.d/

those drop-ins have higher precedence and override the main configuration file. periodt.

files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. when multiple files specify the same option:

for options which accept just a single value, the entry in the file sorted last takes precedence
for options which accept a list of values, entries are collected as they occur in the sorted files

💜 who ships what (the politics of drop-ins)

when packages need to customize the configuration, they can install drop-ins under /usr/. files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages.

drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. this is the rule, and it does not bend. 🙈

it is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering. this also defines a concept of drop-in priorities to allow OS vendors to ship drop-ins within a specific range lower than the range used by users. this should lower the risk of package drop-ins accidentally overriding drop-ins defined by users. oops-proofing, basically. 💀

it is recommended to use the range 10-40 for drop-ins in /usr/ and the range 60-90 for drop-ins in /etc/ and /run/, to make sure that local and transient drop-ins take priority over drop-ins shipped by the OS vendor.

🌟 how to yeet a vendor config

to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file. it's giving "i'm not here". 🫥

⭐ OPTIONS ⭐

the following options are understood in both the "[SysExt]" and "[ConfExt]" sections:

🧚 Section Options

Mutable= — set the mutable mode for system extensions. takes one of "no", "yes", "auto", "import", "ephemeral", or "ephemeral-import". for details about the modes, see the --mutable= option in systemd-sysext(8). defaults to "no".

added in version 259.

ImagePolicy= — set the image policy. takes an image policy string as argument, as per systemd.image-policy(7). for details, see the --image-policy= option in systemd-sysext(8).