systemctl daemon-reload: When to Run It—and What It Doesn't Do

Editing a systemd service configuration file does not automatically update the service's version being used by systemd. Running the command "systemctl daemon-reload" does not restart the service either. These are two separate actions that can easily be confused, often leading to services still running with outdated configurations.

To clarify, when a service's management changes, there are three distinct elements to consider: the unit file on disk, systemd's in-memory configuration, and the actively running service process. The command "daemon-reload" updates the second layer by syncing it with the first, but it does not restart or otherwise signal the process in the third layer.

Therefore, it is useful to remember the rule: after editing a unit file, reload systemd, and then restart the service if it requires the updated unit definition. The typical workflow after editing a unit file involves these two commands: "sudo systemctl daemon-reload" followed by "sudo systemctl restart myapp". The first command instructs systemd to re-read unit files, rerun generators, and rebuild its dependency tree.

The second stops and starts the myapp service, incorporating the updated unit definition into the new process. If you only execute "daemon-reload", the existing service process will continue running. On the other hand, if you only use "restart", systemd may start the service using the unit definition it had already loaded. Both actions are crucial when you've altered a unit and wish for the service to utilize the new definition.

When discussing how the system restarts a systemd service, it's essential to separate the service's behavior from systemd's own behavior. When restarting a systemd service, the "restart" command differs from the "reload" command. The "restart" command stops and starts the service, applying the new unit definition to the new process.

The "reload" command, on the other hand, just updates the service's in-memory configuration without restarting it. Understanding when systemd requires a "daemon-reload" involves editing, manually creating, moving, removing, or modifying a unit file or drop-in. This includes changes to directives such as ExecStart, User, Environment, or dependency settings.

Similarly, any changes made directly to a drop-in override stored in a directory like myapp.service.d/ also require a "daemon-reload" to reload systemd's view of the units. You can verify whether systemd detects changes made to a unit file on disk by using the command "systemctl status myapp". This command may provide a warning indicating that the unit has changed on disk and that "daemon-reload" is necessary.

A more focused check can be done using the command "systemctl show myapp --property = NeedDaemonReload". While "systemctl status" is useful for confirming if a change was made to a unit file, it also provides information about a unit's current state, recent log output, and more. There are certain situations where checking for "daemon-reload" might not be necessary.

If the application's own configuration file is edited, such as an Nginx configuration file, it is not the same as editing a systemd unit. In this case, systemd's "reload" mechanism should be used instead, for example, by running "sudo systemctl reload myapp". Some services do not support the "reload" command; in such cases, a "restart" may be necessary instead.

The command "systemctl edit" automatically reloads the configuration when it successfully completes the edit of a unit file. This is not something you need to do manually with "daemon-reload". However, there is an exception: the "systemctl edit --global" command does not automatically reload the configuration. Global changes will only take effect on subsequent logins.

One exception to the automatic reloading process is when you edit a unit file "globally". In such cases, the reload does not occur automatically, and you may need to run "daemon-reload" manually. Another point of confusion is the difference between a package installation or upgrade and a manual installation or configuration change.

Packages often include instructions to reload systemd after installation or upgrade, but this depends on how the package was built. If you manually install a package or copy a unit file yourself, ensure the reload has occurred. Check the service status for any warnings or run "daemon-reload" if the unit file on disk has changed.

It's essential not to confuse these commands when working with systemd. "systemctl daemon-reload" only updates systemd's view of unit files and dependency tree; it does not change what a running service has already loaded. "systemctl reload myapp" updates the service's own configuration, but only if the service supports this command.

"systemctl restart myapp" restarts the service process, ensuring it runs under the new unit definition. When a systemd service needs to be restarted and its unit definition updated, the recommended sequence is to first "reload systemd" using "daemon-reload", and then restart the service.