Find unit files and overrides

Unit files live in more than one place, and the location decides who owns them.

Packages normally install unit files under /usr/lib/systemd/system or /lib/systemd/system (on Debian and Ubuntu the two are the same directory). Treat those files as vendor property. Local administrator changes belong under /etc/systemd/system, and anything there wins over the vendor copy.

The classic mistake is editing the vendor file in place. It works until the next package upgrade silently replaces the file, and your change is gone with no warning.

See the effective configuration

Use systemctl cat to see every fragment systemd combined for a unit, with the path of each one:

systemctl cat ssh.service

# /usr/lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
...
# /etc/systemd/system/ssh.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/sshd -D -p 2222

The second block is a drop-in: a small file that overrides only the settings it names. The vendor unit stays untouched, and the local difference is explicit.

Create a drop-in with systemctl edit

systemctl edit opens an editor on the right file, creating it if needed:

sudo systemctl edit ssh.service

It writes to /etc/systemd/system/ssh.service.d/override.conf and runs daemon-reload for you when you save. systemctl edit --full instead copies the whole unit into /etc/systemd/system, which you rarely want.

One drop-in gotcha: list settings like ExecStart= append rather than replace. To change the command you must clear it first with an empty assignment, then set the new value — exactly what the override above does. If you skip the empty line, systemd complains that the service has two ExecStart= lines.

To audit a whole machine, systemd-delta lists every unit that differs from its vendor version.

Run systemctl cat ssh.service on your server and read where each fragment comes from. Then open sudo systemctl edit ssh.service, note the target path in the editor comment, and leave without saving.