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

Editing a systemd unit file does not automatically update the version systemd is using. And running systemctl daemon-reload does not restart the service. Those are separate steps—and confusing them is a common reason a service keeps behaving as if its old configuration were still in place.

Think in three layers

When you change how a service is managed, there are three things to keep distinct:

1. The unit file on disk — for example, /etc/systemd/system/myapp.service or a drop-in override.
2. systemd’s in-memory configuration — the unit definitions and dependency tree it has loaded.
3. The running service process — the program that is currently executing.

daemon-reload syncs the second layer with the first. It does not restart or signal the process in the third layer.

That makes this a useful rule of thumb: reload systemd after changing a unit; restart the service if it needs to run under the changed unit.

The usual workflow after editing a unit

For a unit file you edited directly, the sequence is:

sudo systemctl daemon-reload
sudo systemctl restart myapp

The first command tells systemd to re-read unit files, rerun generators, and rebuild its dependency tree. The second stops and starts myapp, applying the updated unit definition to the new process.

If you only run daemon-reload, the current process keeps running. If you only run restart, systemd may start the service using the unit definition it already had loaded. Both steps matter when you have changed a unit and want the service to use the new definition.

For a broader explanation of what happens when you restart a systemd service, including how restart differs from reload, keep the effect on the service separate from the effect on systemd itself.

When does systemd need a daemon reload?

Run sudo systemctl daemon-reload after manually creating, editing, moving, or removing a unit file or drop-in. That includes changes to directives such as ExecStart, User, Environment, or dependency settings.

A drop-in is an override stored in a directory such as myapp.service.d/. If you create or edit one directly, systemd needs to reload its view of the units before it can use the updated definition.

You can check whether systemd reports that a unit changed on disk with:

systemctl status myapp

The output may include a warning that the unit changed on disk and that daemon-reload is needed. For a focused check, you can also query:

systemctl show myapp --property=NeedDaemonReload

systemctl status is useful for more than this warning: it also gives you a snapshot of a unit’s state and recent log output. Here’s a practical guide to reading systemctl status output when you’re checking what happened after a change.

Cases where you can skip it

You changed the application’s own configuration

Editing an application config file—such as an Nginx configuration file—is not the same as editing a systemd unit. daemon-reload will not make the application read its own configuration.

Use the service’s supported reload mechanism if it has one:

sudo systemctl reload myapp

A service reload asks the running process to re-read its application configuration; it does not mean systemd is re-reading unit files. Not every service supports reload. If yours does not, a restart may be necessary instead.

You used systemctl edit

When systemctl edit myapp or systemctl edit --full myapp completes successfully, systemd reloads its configuration automatically. You generally do not need to run daemon-reload again for that edit.

There is an exception: systemctl edit --global deliberately skips that reload. Global changes take effect on subsequent logins.

A package installed or upgraded the unit

Packages often arrange to reload systemd as part of installation or upgrade, but that depends on how the package was built. If you manually install a package or copy a unit file yourself, don’t assume the reload happened. Check the service status for a warning or run daemon-reload if the unit file changed on disk.

Don’t confuse these commands

Command	What it acts on	Restarts the service?
systemctl daemon-reload	systemd’s unit files and dependency tree	No
systemctl reload myapp	The running service’s own configuration	No, if supported
systemctl restart myapp	The service process	Yes
systemctl daemon-reexec	The systemd manager process itself	No

daemon-reexec is not a more forceful way to restart a service. It re-executes the systemd manager and is mainly relevant for debugging or after upgrading systemd itself—not routine unit-file edits.

A quick decision guide

• Changed a unit or drop-in manually? Run daemon-reload; restart the service if it should use the new definition.
• Changed the app’s own config? Use its supported reload command, or restart it if necessary. daemon-reload is not the fix.
• Used systemctl edit? The reload is normally handled for you.
• Unsure whether systemd sees the change? Check systemctl status SERVICE for a “changed on disk” warning.

The key distinction is simple: daemon-reload updates systemd’s view of unit files; it does not change what a running service has already loaded. When both the unit definition and the running process need updating, reload systemd first, then restart the service.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.