How to reload the systemd manager configuration

Changing a unit file, drop-in override, or generator-backed configuration does not take effect until the systemd manager rereads its unit definitions. Running systemctl daemon-reload makes new or changed units visible to the manager and rebuilds the dependency graph around the updated files.

System units are normally loaded from /etc/systemd/system, /run/systemd/system, and /usr/lib/systemd/system, with any *.d/*.conf drop-ins merged on top of the main unit file. The current upstream systemctl and systemd.generator documentation states that daemon-reload reruns generators, reloads unit files from disk, and recreates the dependency tree, so changes from unit overrides, new unit files, and generated units such as those derived from /etc/fstab can be picked up without rebooting.

daemon-reload only refreshes systemd's view of unit definitions. It does not reload an application's own configuration file and it does not restart running services, so unit changes such as ExecStart=, Environment=, dependencies, or install symlinks usually still need a follow-up start, restart, reload, or enable action. For per-user units, use systemctl --user daemon-reload instead of the system manager command.

1. Check whether a loaded unit now needs a manager reload.

   $ systemctl show -p FragmentPath -p DropInPaths -p NeedDaemonReload reload-demo.service
   FragmentPath=/etc/systemd/system/reload-demo.service
   DropInPaths=
   NeedDaemonReload=yes

   Replace reload-demo.service with the actual unit name. When NeedDaemonReload=yes, systemd is still using an older in-memory copy of the unit definition. An empty DropInPaths= line after creating a new override is another sign that the manager has not reread the changed files yet.

2. Reload the systemd manager configuration.

   $ sudo systemctl daemon-reload

   This reruns generators, reloads unit files, and rebuilds the dependency tree. Changes under /etc/systemd/system, /run/systemd/system, and generated units are picked up here.

   If the edited file was written manually, a syntax check such as sudo systemd-analyze verify /etc/systemd/system/unit-name.service helps catch parser errors before the reload.

   After editing /etc/fstab, /etc/crypttab, or other generator-backed sources, daemon-reload reruns the generators but it does not mount, unlock, or start anything by itself.

3. Confirm that the unit no longer reports a pending manager reload.

   $ systemctl show -p NeedDaemonReload reload-demo.service
   NeedDaemonReload=no

   If the unit still reports yes, recheck the edited files for syntax errors, incomplete writes, or additional pending changes.

4. Confirm that a new or changed unit is now visible from the manager state.

   $ systemctl list-unit-files reload-demo.service
   UNIT FILE           STATE  PRESET
   reload-demo.service static -
   
   1 unit files listed.

   For an existing unit, systemctl status unit-name.service or systemctl cat unit-name.service can also confirm that systemd is reading the updated definition. The static state means the unit has no Install section, so it can be started or pulled in by another unit but not enabled directly.

5. Apply the changed unit settings to the affected service.

   $ sudo systemctl restart reload-demo.service
   
   $ systemctl status --no-pager --full reload-demo.service | head -n 8
   ● reload-demo.service - Reload demo service
        Loaded: loaded (/etc/systemd/system/reload-demo.service; static)
       Drop-In: /etc/systemd/system/reload-demo.service.d
                └─override.conf
        Active: active (exited) since Mon 2026-04-13 08:39:09 UTC; 2ms ago
       Process: 145 ExecStart=/bin/sh -c printf "base-run\n" >> /run/reload-demo.log (code=exited, status=0/SUCCESS)
      Main PID: 145 (code=exited, status=0/SUCCESS)

   Use start for a brand-new unit, restart after changing unit settings that affect the running process, or reload only when the service itself supports reloading its own application configuration.

   systemctl reload unit-name.service is different from systemctl daemon-reload. The first asks the service process to reread its own configuration, while the second makes systemd reread unit definitions.

   Related: How to start a service using systemctl
   Related: How to restart a service using systemctl
   Related: How to reload a service using systemctl