Systemd presets are how package managers decide if a service should be enabled by default when they install it.
Let’s see it in action. Imagine we’re installing nginx.
# First, check if nginx is installed and if its service is enabled
systemctl is-enabled nginx.service
# Expected output if not enabled: disabled
# Now, install nginx (using apt as an example)
sudo apt update
sudo apt install nginx
# After installation, check the status again
systemctl is-enabled nginx.service
# Expected output if preset worked: enabled
This "magic" happens because of files located in /etc/systemd/system/. When a package installs a service unit file (like nginx.service), it also typically places a corresponding preset file in this directory.
The systemd daemon reads these preset files during boot or when systemctl daemon-reload is run. A preset file is simply a text file named *.preset (e.g., nginx.preset) containing lines like:
enable nginx.service
disable ssh.service
static apache2.service
The enable command tells systemd to create the necessary symlinks in /etc/systemd/system/multi-user.target.wants/ (or similar target directories) so that nginx.service starts on boot. disable does the opposite, removing those symlinks. static means the service is enabled if a dependency requires it, but not started by default on its own.
The problem systemd presets solve is ensuring that when you install software with a background service, that service is automatically configured to start when you need it, without manual intervention. It standardizes the enablement behavior across different packages and distributions.
The core components you interact with are the .service unit files themselves (usually found in /usr/lib/systemd/system/ or /lib/systemd/system/) and the .preset files in /etc/systemd/system/. The systemctl enable and systemctl disable commands are the user-facing tools that manipulate the symlinks based on the directives in the preset files.
When a package manager installs a new service, it drops its .service file into /usr/lib/systemd/system/. It also typically drops a .preset file into /etc/systemd/system/. This .preset file tells systemd how to configure the service’s default state (enabled, disabled, static). If the package manager doesn’t provide a .preset file, the service will usually remain disabled by default, requiring a manual systemctl enable <service_name> command.
Most people don’t realize that the .preset files themselves are often managed by sub-packages or configuration packages within a distribution’s ecosystem. For instance, on Debian/Ubuntu, you might find nginx-common or a similar meta-package is responsible for installing the nginx.preset file that enables nginx.service. If that meta-package isn’t installed, or if it’s configured not to enable the service, then nginx.service will remain disabled even after nginx-core is installed.
The actual symlinks created by systemctl enable point from a target directory (like multi-user.target.wants) to the service unit file. For example, sudo systemctl enable nginx.service creates /etc/systemd/system/multi-user.target.wants/nginx.service pointing to /usr/lib/systemd/system/nginx.service. The preset files automate this linking process based on package installation.
If you’re troubleshooting why a service isn’t starting after installation, beyond checking the service status with systemctl status <service_name> and logs with journalctl -u <service_name>, the first place to look is for a corresponding .preset file in /etc/systemd/system/ that dictates its default enablement state.
The next thing you’ll likely encounter is understanding how systemd targets and dependencies influence service startup order.