A configuration-management run adds the drop-in /etc/systemd/system/app.service.d/override.conf containing an [Service] section with a new ExecStart= line, and after daemon-reload the unit refuses to start, complaining it has more than one ExecStart=. Why does that happen, and how do you correctly replace a directive from a drop-in?

## Two merge rules, not one When systemd assembles a unit it parses the main unit file, then each drop-in in order. Every assignment it meets is applied to the unit under construction, and the *type of the setting* decides what "applied" means: - **Single-valued settings** hold one value: `User=`, `Type=`, `WorkingDirectory=`, `MemoryMax=`, `RestartSec=`. The last assignment parsed wins, so a drop-in simply overrides the main file. This is the behaviour people generalise from, and it is why the trap is so easy to fall into. - **List-valued settings** accumulate: `ExecStart=`, `ExecStartPre=`, `ExecStartPost=`, `Environment=`, `EnvironmentFile=`, `ReadWritePaths=`, `After=`, `Wants=`, `AmbientCapabilities=`. Each assignment adds to what is already there. So a drop-in containing one `ExecStart=` line does not replace the vendor's `ExecStart=` — it adds a second one. ## Why a second ExecStart= is fatal Several `ExecStart=` lines are legal for a `Type=oneshot` service, where they mean "run these commands in sequence". For every other service type, systemd supervises a single main process and rejects the unit outright rather than guessing which command you meant. The unit fails to load, so it does not just misbehave — it will not start at all, and on the next reboot the host comes up without it. The same shape appears with `Environment=`: two assignments of the same variable are not an error, so the unit starts, and which value wins is decided by parse order rather than by intent. That failure is quieter and lands in production more often. ## The empty assignment systemd's documented reset for a list-valued setting is an assignment with no value at all. A bare key and `=` clears everything accumulated so far for that key; assignments after it start a fresh list. So the correct drop-in is two lines: ```ini [Service] ExecStart= ExecStart=/usr/local/bin/app --new-flag ``` Order matters — the reset must come before the new value, or it wipes what you just set. The reset also only affects the setting it names; nothing else in the merged unit is disturbed. The same idiom clears the other lists: a bare `Environment=` drops all inherited environment assignments, a bare `ReadWritePaths=` clears an inherited sandbox exception list, and so on. It is worth internalising as the single answer to "how do I *remove* something a vendor unit set", because there is no delete syntax beyond it. ## Verifying the merge Two commands settle any argument about what a unit is actually configured to do: ``` systemctl cat app.service systemctl show -p ExecStart -p Environment app.service ``` `systemctl cat` prints the main unit file and every drop-in with its path, in the order they were applied — so you can see the reset line sitting before the new value. `systemctl show -p` prints the property as systemd resolved it after merging, which is the ground truth. If `show` reports two `ExecStart` entries, the reset is missing or misordered, whatever the files look like. Before deploying, `systemd-analyze verify /etc/systemd/system/app.service` loads the unit the way the manager would — including its drop-ins — and reports the problem without disturbing the running service. In a configuration-management pipeline that check belongs in CI, because the failure mode here is a unit that will not start, discovered at the worst possible moment. ## The operational lesson This is a class of incident, not a one-off: the change looks correct in review, the drop-in file is exactly what the ticket asked for, and the unit is dead until someone reads the journal. Three habits prevent it. Know which of the settings you touch are list-valued. Always pair a list-valued override with its reset line. And after any automated push that touches unit files, assert the resolved property with `systemctl show -p` rather than assuming that a written file equals an applied setting. When a change is large enough that half the vendor's `[Service]` section is being reset, the honest move is `systemctl edit --full` to take ownership of the whole unit, and to accept the maintenance cost that comes with the fork — a drop-in full of reset lines is harder to reason about than an explicit copy.