Modify a Service the Right Way: Drop-in Overrides

Every service is described by a unit file, and those files live in two different trees that systemd treats very differently.

• `/usr/lib/systemd/system/` (also /lib/...) holds the vendor units — the ones shipped by the package that installed the service. This directory belongs to the package manager. When the package updates, everything here is overwritten.
• `/etc/systemd/system/` holds the administrator's configuration — your changes. systemd gives this tree higher priority, and the package manager never touches it.

So the golden rule is: never edit a file under `/usr/lib/systemd/system/`. Two things go wrong if you do. First, the next dnf/apt update silently reverts your change, and you get to debug why a setting you 'definitely made' has vanished. Second, you have now forked the vendor's file, so you will not receive their future fixes to it either. The supported way to change a service is to put your change in /etc/systemd/system/ instead — and the neatest form of that is a drop-in.

A drop-in is a partial unit file placed in a directory named after the unit with a .d suffix: /etc/systemd/system/<unit>.service.d/. Any file ending in .conf inside it is a drop-in. You do not repeat the whole unit — you write only the [Section] and the one or two directives you want to change.

Here is the model to hold in your head: at load time systemd reads the base vendor unit first, then reads every `.conf` in the `.d` directory and layers each directive on top, last value winning. Your drop-in is a patch, not a replacement. That is why it survives package updates cleanly (the vendor file underneath can change and your patch still applies) and why it is the RHCSA/LFCS-preferred way to tune a service. A one-line file that sets Restart=always is a complete, correct override — everything else about the service keeps coming from the vendor unit.

Creating the .d directory by hand works and is worth doing once to see the mechanism, but the everyday tool is `systemctl edit`. Running systemctl edit webapp opens your $EDITOR on a fresh, empty drop-in, and on save it does three chores for you: it creates the <unit>.service.d/ directory, writes your text into override.conf, and runs daemon-reload so the change is picked up. You type only the section and directives — the same small patch as before.

There is a second form, `systemctl edit --full`. Instead of a drop-in, this copies the entire vendor unit into /etc/systemd/system/ and opens that for editing. The copy shadows the vendor file completely. Reach for --full only when you genuinely need to rewrite most of the unit (or change something a drop-in cannot cleanly patch); for a directive or two, the plain drop-in is lighter and keeps you riding the vendor's future updates. Whichever you use, the change lands under /etc/, never in /usr/lib/.

On this box systemctl edit cannot run. On Ubuntu it wants a bus and an interactive tty, and answers Cannot edit units if not on a tty.; on Rocky the stand-in systemctl answers unsupported verb 'edit'. That costs you nothing, because what it writes is precisely the file you wrote by hand in the last step — edit is a convenience wrapper, not a different mechanism. Author the drop-in by hand here; reach for edit on a real host.

Most directives are single-valued: put Restart=always in a drop-in and it simply replaces whatever the vendor set. But a handful of directives are list-valued — ExecStart, ExecStartPre, Environment, After, and friends — and these accumulate rather than replace. If the vendor unit has ExecStart=/usr/bin/python3 -m http.server 8000 and your drop-in adds ExecStart=/usr/bin/python3 -m http.server 8080 --bind 127.0.0.1, systemd does not swap one for the other; for ExecStart specifically it now sees two start commands and refuses to load, and for the additive ones you get both entries.

The idiom that fixes this is reset-then-set: assign the directive empty first to clear the inherited list, then assign the value you actually want. For ExecStart that is two lines — an empty ExecStart= followed by the real one. It looks odd the first time, but it is the documented way to say 'forget what the vendor put here, use this instead.' Whenever an override of a list directive behaves like it was added rather than replaced, this is the reason.

Editing a file on disk changes nothing that is already running — systemd has the old unit cached in memory. Two verbs bridge that gap, and they are not the same thing. `systemctl daemon-reload` re-reads unit files from disk so systemd knows about your edit; you run it after any change to a unit or drop-in (and systemctl edit runs it for you). `systemctl restart <unit>` then stops and starts the service so a changed ExecStart, resource limit, or environment actually takes effect on the running process. (reload — lowercase, no daemon- — is different again: it asks the service to re-read its own config, like nginx re-reading nginx.conf, and only works if the unit defines an ExecReload.)

Then verify instead of hoping. systemctl cat <unit> shows the base unit with your drop-in appended, so you can confirm the file is where you meant it. systemctl show -p <Directive> <unit> prints the single effective value systemd computed after merging everything — the ground truth. Checking the effective value is how you catch a drop-in that landed in the wrong directory, or a list directive you forgot to reset.

Neither daemon-reload nor show does anything useful on this box. On Ubuntu both need the bus; on Rocky the stand-in systemctl accepts daemon-reload and does nothing, and does not know show. What you can do here is the check that catches most override mistakes before they ever reach a service manager: parse the unit file offline with systemd-analyze verify. It reads unit files straight from disk, needs no PID 1, and is exactly what this platform's systemd rooms grade you on.

Every drop-in in this lesson changed what a service does. The same mechanism is how you change what a service may touch: the Sandbox a systemd Service lesson (systemd-sandboxing-guide) puts ProtectSystem=, NoNewPrivileges=, CapabilityBoundingSet= and the other confinement directives in a drop-in, and measures the result with systemd-analyze security --offline=true.