Find systemd Configuration Overrides Before You Edit a Unit

You will finish with a repeatable way to find the configuration layer that changes systemd behaviour, inspect the winning file and review a diff before touching anything. The examples use systemd-delta from systemd 255, package version 255.4-1ubuntu8.17 on this machine.

Allow about ten minutes for a first pass. You need a shell and the systemd package. Reading the configuration usually needs no elevated privileges; use sudo only if a later inspection command cannot read a file. This guide does not edit units, reload systemd or restart services.

1. Confirm the installed command

Start with the local binary and its version. These are ordinary, read-only commands:

$ command -v systemd-delta
/usr/bin/systemd-delta
$ systemd-delta --version
systemd 255 (255.4-1ubuntu8.17)

Your package revision may differ. Keep the installed manual beside you when working on another distribution, because the available configuration paths and output details are version-specific.

2. List all differences

Run the default report without sudo:

$ systemd-delta --no-pager

The command compares configuration files across systemd's search paths. In the usual priority order, /etc/ wins over /run/, which wins over lower-priority locations such as /usr/lib/. A file with the same name in a higher-priority directory therefore takes precedence over the packaged or vendor copy.

--no-pager keeps the result in the terminal and makes it safer to capture in a ticket or pipe to another read-only command. Without it, the program may send output through a pager. A report ending with a count such as 21 overridden configuration files found is a summary, not an instruction to change all those files.

Typical entries carry a type label:

• overridden means the higher-priority file differs from its lower-priority counterpart.
• equivalent means the lower-priority file is shadowed even though the contents match.
• redirected means the path points at another file through a link or equivalent redirection.
• masked identifies a file hidden by a mask, commonly a symlink to /dev/null.
• extended identifies unit drop-in files under a .d directory.

A masked unit is a service-management decision, not merely a harmless duplicate. Do not remove a mask or start the unit until you know why it was applied.

3. Narrow the report to system units

To focus on unit files and their drop-ins, pass the suffix named by the manual:

$ systemd-delta --no-pager systemd/system

The argument is split into an optional prefix and suffix. systemd/system means the systemd/system configuration directory across the available search paths. This is useful when a service appears to ignore a vendor unit or when you suspect an administrator drop-in.

For a runtime-only view, use the directory prefix:

$ systemd-delta --no-pager /run

Runtime files can be generated by boot tooling or another process and may disappear on reboot. Treat an entry under /run as temporary until you identify its owner. The command itself does not create or remove those files.

4. Show only the differences you need

Use --type with a comma-separated list. For example, show changed overrides but not masks or drop-ins:

$ systemd-delta --no-pager --type=overridden systemd/system

To inspect drop-in files, select extended:

$ systemd-delta --no-pager --type=extended /run/systemd/system

The recognised types are masked, equivalent, redirected, overridden, extended and unchanged. The last type includes unmodified files, which can make a deliberately narrow investigation noisy. If a filter returns zero results, that means no matching entries were found in the selected scope; it does not prove that systemd has no configuration elsewhere.

5. Read the diff before deciding what to edit

Ask for a diff alongside changed overrides:

$ systemd-delta --no-pager --type=overridden --diff systemd/system

In this version, --diff takes a boolean value and defaults to true when the value is omitted. It applies when a modified file is overridden. The output shows the lower-priority file and the higher-priority file, so compare the actual paths before opening an editor.

Do not assume that the visible file in /usr/lib/systemd/system is the one to edit. Packaged files are normally replaced during an upgrade. A local change belongs in the appropriate higher-priority location, often an administrator drop-in under /etc/systemd/system/NAME.service.d/, but the correct location depends on the setting and how it was provisioned.

Do not edit a file just because it appears in the report. First identify the owner of the higher-priority file, record its current contents and check whether configuration management will recreate it. If the issue concerns a live service, review the proposed change separately before any reload or restart. Those actions can disrupt service and are outside this read-only check.

6. Investigate a surprising result safely

When an entry is unexpected, copy the two paths from the report and inspect them without changing state:

$ ls -l -- /path/from/the/report
$ sed -n '1,220p' -- /path/from/the/report

Replace the placeholder with an exact path from your output. If a file is unreadable, check its permissions first:

$ test -r -- /path/from/the/report && echo readable || echo not-readable

Only then consider an elevated read such as sudo sed, and avoid copying secrets or credentials into a shared ticket. Never use a broad wildcard with a command that might later be adapted into an editor or removal command.

If you need a machine-readable-looking log, redirect the report to a new file in a directory you control. This changes only that log file, not systemd configuration:

$ systemd-delta --no-pager --type=overridden > "$PWD/systemd-delta-report.txt"
$ test -s "$PWD/systemd-delta-report.txt" && echo report-written

Remove that temporary report when it is no longer needed if it contains paths or operational details. Do not delete any file named by the report as a way to make the warning disappear.