How to edit a systemd unit override

Editing a systemd override changes how one unit starts, stops, or inherits limits without copying the vendor unit into /etc/ and taking ownership of the whole file. That is the safer path when a packaged service only needs a local tweak such as a different restart delay, resource limit, environment value, or ordering rule.

systemd loads the main unit file first and then merges any /etc/systemd/system/unit-name.service.d/*.conf drop-ins on top of it. Current systemctl documentation states that systemctl edit unit.service creates or reopens the default drop-in named override.conf unless a different file is selected with --drop-in=, and the manager configuration is reloaded automatically after a successful save.

The edited override only changes the unit definition that systemd keeps in memory; it does not force a running service process to restart itself. Most service-unit overrides still need a follow-up restart, per-user services should use systemctl --user edit instead of the system manager, and list-style settings such as ExecStart= must be cleared before replacement while dependency settings such as After= or Requires= can only be added in a drop-in, not removed.

Steps to edit a systemd unit override:

Inspect the currently loaded unit before changing it.
```
$ systemctl cat override-demo.service
# /usr/lib/systemd/system/override-demo.service
[Unit]
Description=Override demo service

[Service]
Type=simple
ExecStart=/usr/local/bin/override-demo
Restart=on-failure
RestartSec=5
```
Replace override-demo.service with the real unit name. If the output already includes a Drop-In: section, that shows an existing override that systemctl edit will reopen or extend.

Use systemctl --user cat unit.service for a per-user unit instead of the system manager.
Open the unit's default drop-in override with the editor configured for systemctl.
```
$ sudo systemctl edit override-demo.service
```
Without --full, systemctl edits a drop-in rather than replacing the main unit file. The default target is /etc/systemd/system/override-demo.service.d/override.conf for system units, while per-user units use the corresponding user unit path under the home directory.

Use sudo systemctl edit --drop-in=local.conf override-demo.service when the override should live in a separately named drop-in, or sudo systemctl edit --runtime override-demo.service when the change should disappear at the next reboot.
Add only the directives that should change, under the same section name used by the original unit.
```
[Service]
RestartSec=15
LimitNOFILE=65535
```
Each drop-in file still needs normal section headers such as [Service] or [Unit]. A drop-in overrides only the specified directives and leaves the rest of the vendor unit in place.
Clear list-style settings before replacing them, instead of stacking a second copy on top.
```
[Service]
ExecStart=
ExecStart=/usr/local/bin/override-demo --foreground --port 9443
```
Current systemd.service documentation states that assigning an empty value to ExecStart= resets the existing command list before the new command is added. The same pattern is required for other resettable list settings when entries need to be removed or replaced.

Current systemd.unit documentation states that dependency settings such as After= and Requires= cannot be reset to an empty list in a drop-in. When dependencies must be removed, edit the full unit with sudo systemctl edit --full unit.service instead of a normal override.

Save and close the editor, then confirm that systemd loaded the new drop-in.

$ systemctl show -p DropInPaths -p NeedDaemonReload override-demo.service
DropInPaths=/etc/systemd/system/override-demo.service.d/override.conf
NeedDaemonReload=no

$ systemctl cat override-demo.service
# /usr/lib/systemd/system/override-demo.service
[Unit]
Description=Override demo service

[Service]
Type=simple
ExecStart=/usr/local/bin/override-demo
Restart=on-failure
RestartSec=5

# /etc/systemd/system/override-demo.service.d/override.conf
[Service]
RestartSec=15
LimitNOFILE=65535

Current systemctl documentation states that a successful systemctl edit reloads the unit configuration automatically, which is why NeedDaemonReload=no is the expected post-save state here.

If the drop-in was written manually with a regular editor instead of systemctl edit, run sudo systemctl daemon-reload before expecting the manager to see the new file.

Restart the service so the running process picks up the changed unit settings.
```
$ sudo systemctl restart override-demo.service
```
Most service-unit override changes affect how systemd launches or constrains the service, so restart is the normal follow-up action. A service-specific reload only rereads the application's own configuration and usually does not apply new ExecStart=, environment, dependency, or resource-limit settings.

Related: How to restart a service using systemctl

Confirm that the override is active and that the expected property values are now loaded for the unit.

$ systemctl status --no-pager --full override-demo.service | sed -n '1,8p'
● override-demo.service - Override demo service
     Loaded: loaded (/usr/lib/systemd/system/override-demo.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/override-demo.service.d
             └─override.conf
     Active: active (running) since Mon 2026-04-13 13:41:29 UTC; 2s ago
   Main PID: 482 (override-demo)
      Tasks: 1 (limit: 14335)
     Memory: 916.0K

$ systemctl show -p RestartUSec -p LimitNOFILE override-demo.service
RestartUSec=15s
LimitNOFILE=65535

The Drop-In: path proves that the override file is loaded, while systemctl show confirms the exact value that systemd is using after the restart. Property names do not always match the directive name verbatim, so checking both views is often the quickest way to confirm the change.