Defining Unit File Hierarchies

In this lesson, you will learn how to properly organize custom unit files between system-managed directories and local overrides to maintain a clean, maintainable system configuration.

When working with systemd, understanding where to place your unit files is essential for preventing configuration conflicts and ensuring your customizations survive system updates. There is a strict hierarchy designed to separate vendor-provided defaults from your personal administrative tweaks.

The Two Primary Locations

1. /usr/lib/systemd/system/: This directory is reserved for packages installed by your distribution’s package manager. You should never manually edit files here. If you modify a file in this directory, those changes will likely be wiped out the next time the package is updated.
2. /etc/systemd/system/: This is your workspace. It is intended for custom unit files and configuration overrides. systemd prioritizes files found here over those in /usr/lib/systemd/system/.

Effective Hierarchy Management

The most effective way to manage this hierarchy is through Drop-In Files. If you want to customize a service (e.g., my-app.service) installed by the system, you do not copy the entire file to /etc. Instead, you create a directory named my-app.service.d/ inside /etc/systemd/system/ and place a configuration file inside it:

# Create the directory for overrides
sudo mkdir -p /etc/systemd/system/my-app.service.d/

# Create a drop-in file to change a parameter
echo -e "[Service]\nNice=10" | sudo tee /etc/systemd/system/my-app.service.d/override.conf

By using this structure, the original unit file remains intact in /usr/lib/systemd/system/, ensuring your package manager remains happy. Meanwhile, systemd merges your override.conf settings with the base unit, applying your specific changes at runtime. If you need to revert to the default behavior, you simply delete your /etc override file rather than trying to restore the original vendor file manually.

This approach keeps your administrative intent clearly separated from the underlying system defaults, making your service lifecycle management much more robust.

Key Takeaway: Always store custom unit files and configuration overrides in /etc/systemd/system/ to ensure your changes are preserved and to maintain a clean separation from vendor-provided defaults.