How to revert a systemd unit override

Reverting a systemd unit override removes local changes that altered how a service, socket, timer, or other unit is loaded on the current host. That is useful after testing a temporary workaround, undoing a bad systemctl edit change, or restoring a packaged unit before a clean troubleshooting pass.

systemd loads vendor unit files from directories such as /usr/lib/systemd/system and then applies any higher-priority local overrides from /etc/systemd/system or /run/systemd/system. Current upstream systemctl documentation states that systemctl revert unit.service removes matching drop-ins from both the persistent and runtime unit paths, removes a full local unit replacement when a matching vendor unit exists, and also clears a mask on that unit.

Reverting the unit definition does not replace an already running service process by itself. If the override changed launch-time settings such as ExecStart=, resource limits, environment variables, or restart timing, restart the unit after the revert so the running process matches the restored vendor definition. For per-user units, use systemctl --user revert instead of the system manager command, and note that a unit with no vendor copy under /usr is not deleted by revert.

1. Inspect the currently loaded unit before removing the override.

   $ systemctl cat override-demo.service
   # /usr/lib/systemd/system/override-demo.service
   [Unit]
   Description=Override demo service
   
   [Service]
   Type=simple
   ExecStart=/usr/bin/sleep infinity
   Restart=always
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target
   
   # /etc/systemd/system/override-demo.service.d/override.conf
   [Service]
   RestartSec=15
   Environment=SOURCE=persistent
   
   # /run/systemd/system/override-demo.service.d/runtime.conf
   [Service]
   Environment=SOURCE_RUNTIME=runtime

   Replace override-demo.service with the real unit name. Any extra section printed after the vendor unit shows that one or more drop-ins are currently in effect.

   Use systemctl --user cat unit.service for a per-user unit.

2. Revert the unit to the vendor definition.

   $ sudo systemctl revert override-demo.service
   Removed "/etc/systemd/system/override-demo.service.d/override.conf".
   Removed "/etc/systemd/system/override-demo.service.d".
   Removed "/run/systemd/system/override-demo.service.d/runtime.conf".
   Removed "/run/systemd/system/override-demo.service.d".

   Reverting a remote-access, network, storage, or boot-critical unit can remove locally required parameters immediately. Keep console or other out-of-band access available before reverting units such as sshd.service, network daemons, or mount-related units.

   Current upstream systemctl behavior also removes a full local replacement file when a matching vendor unit exists under /usr, and it unmasks the unit if it was masked.

3. Confirm that the manager is back on the vendor file and that no drop-ins remain loaded.

   $ systemctl show -p FragmentPath -p DropInPaths -p UnitFileState -p NeedDaemonReload override-demo.service
   FragmentPath=/usr/lib/systemd/system/override-demo.service
   DropInPaths=
   UnitFileState=disabled
   NeedDaemonReload=no
   
   $ systemctl cat override-demo.service
   # /usr/lib/systemd/system/override-demo.service
   [Unit]
   Description=Override demo service
   
   [Service]
   Type=simple
   ExecStart=/usr/bin/sleep infinity
   Restart=always
   RestartSec=5
   
   [Install]
   WantedBy=multi-user.target

   FragmentPath should point back to the vendor unit path and DropInPaths= should be empty. In verified output here, NeedDaemonReload=no immediately after revert, so a separate daemon-reload was not required for the revert itself.

4. Restart the service when the reverted settings affect how the process is launched or constrained.

   $ sudo systemctl restart override-demo.service

   In verified runtime output, the loaded ExecStart= command returned to the vendor value immediately after revert, but the already running process kept the old command line until a restart replaced it. The same rule applies to many override changes involving environment, limits, sandboxing, and start commands.

   Related: How to restart a service using systemctl

5. Verify that the unit is now loaded from the vendor path and is running in the expected state.

   $ 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; disabled; preset: enabled)
        Active: active (running) since Mon 2026-04-13 14:22:07 UTC; 2s ago
      Main PID: 351 (sleep)
         Tasks: 1 (limit: 14335)
        Memory: 908.0K
           CPU: 2ms
        CGroup: /system.slice/override-demo.service

   The restored Loaded: path is the quickest human-readable proof that the vendor unit is active again. When the revert also cleared a mask, systemctl is-enabled unit.service commonly changes from masked back to disabled, enabled, or static depending on the vendor unit.

   Related: How to check service status using systemctl
   Related: How to check whether a service is enabled using systemctl

6. Check whether the unit is local-only when revert leaves the main file in place.

   $ systemctl show -p FragmentPath override-demo.service
   FragmentPath=/etc/systemd/system/override-demo.service

   If the fragment still points to /etc/systemd/system or /run/systemd/system after revert, the unit may not have a vendor-supplied copy under /usr. Current upstream documentation states that systemctl revert does not delete such local-only units, so remove or replace the file manually only after confirming that the unit was intended to be local.

   When the goal is only to remove one or two directives instead of restoring the whole vendor unit, edit the drop-in again rather than reverting it entirely.

   Related: How to edit a systemd unit override