systemctl daemon-reload vs reload: Which One You Actually Need, and When

systemctl daemon-reload and systemctl reload <service> sound alike and do completely different things. daemon-reload tells systemd itself to re-read unit files after you have edited a .service file - it does not touch the running service. reload <service> tells the service to re-read its own application config, usually by sending it a SIGHUP, without restarting. So you run daemon-reload when you changed how systemd manages the service, and reload when you changed what the application does. Confusing the two is why people edit a unit file, run the wrong command, and wonder why nothing changed.

The clean way to remember it: daemon-reload is for systemd’s paperwork, reload is for the app’s settings. They operate on different files and different processes.

Table of contents

• Two different things named almost the same
• When you need daemon-reload
• When you need reload (not daemon-reload)
• The command that catches you out
• A decision table you can keep
• How this fits the rest of the stack
• FAQ

Two different things named almost the same

The word “reload” is doing double duty, and that is the entire source of confusion.

• systemctl daemon-reload acts on systemd. It re-reads all the unit files (/etc/systemd/system/*.service, /lib/systemd/system/*, drop-ins) and rebuilds systemd’s internal picture of your services. It does not stop, start, or signal any running service.
• systemctl reload <service> acts on the service. It asks that specific running program to reload its own configuration - Nginx re-reads nginx.conf, for example - typically via a SIGHUP, without a restart.

Different target, different file, different effect. daemon-reload is about the unit definition that tells systemd how to run the thing. reload is about the app’s config once it is running.

When you need daemon-reload

Run daemon-reload whenever you change the unit file - the thing that defines how systemd launches and supervises the service. That includes:

• Editing a .service file’s ExecStart, Environment, Restart, User, or any other directive.
• Adding a new unit file for a service you just created.
• Adding or editing a drop-in override in /etc/systemd/system/<service>.service.d/.

Until you run it, systemd is still using the old definition it loaded at boot. The classic symptom: you edit ExecStart, run systemctl restart myapp, and it restarts with the old command - because restart used systemd’s cached, pre-edit unit. The sequence is always:

sudo systemctl daemon-reload
sudo systemctl restart myapp

First reload the definition, then restart the service so it launches under the new one.

When you need reload (not daemon-reload)

Run reload <service> when you changed the application’s configuration, not the unit file, and the service supports reloading:

sudo systemctl reload nginx

This is the zero-downtime path: Nginx re-reads its config and keeps serving without dropping connections. Postgres, Apache, and other well-behaved daemons support it too. Nothing about systemd’s unit definition is involved here - you did not touch the .service file, so daemon-reload would do nothing useful.

If a service does not support reload, systemd tells you, and you fall back to restart. systemctl reload-or-restart <service> picks automatically: it reloads if the service can, and restarts if it cannot.

The command that catches you out

The trap is editing a unit file and reaching for restart alone:

# edit /etc/systemd/system/myapp.service ...
sudo systemctl restart myapp   # restarts with the OLD definition

systemd loaded the unit files at boot and caches them. restart stops and starts the process, but from the cached definition - it does not re-read the file you just changed. Your edit appears to have no effect, and you burn twenty minutes convinced the change is wrong when it simply was not loaded.

Helpfully, recent systemd versions detect this and print a warning like “Warning: The unit file changed on disk. Run ‘systemctl daemon-reload’.” If you see that, it is telling you exactly what happened. Run daemon-reload, then restart, and the edit takes effect.

A decision table you can keep

Boil it down to what you changed:

• Edited a .service unit file or a drop-in -> daemon-reload, then restart (or reload) the service.
• Edited the application’s own config (nginx.conf, postgresql.conf) and the service supports reloading -> reload <service>.
• Edited the application’s config but the service cannot reload -> restart <service>.
• Not sure whether it reloads -> reload-or-restart <service>.
• Created a brand-new unit file -> daemon-reload first so systemd sees it, then enable/start.

The one-line version: change the unit, use daemon-reload; change the app config, use reload. Keep that straight and systemd stops being mysterious.

How this fits the rest of the stack

Whatever you decide here, the cost of it eventually shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.

Useful related references:

• Services on RunxBuild

FAQ

What does systemctl daemon-reload do?

It tells systemd to re-read all unit files and rebuild its internal view of your services. You run it after editing or adding a .service file or drop-in, so systemd picks up the new definition. It does not stop, start, or restart any running service - you still restart the service afterward to apply the change.

What is the difference between daemon-reload and reload?

daemon-reload acts on systemd and re-reads unit files after you edit them. reload <service> acts on the service itself, telling it to re-read its own application config (usually via SIGHUP) without restarting. Different targets: one is systemd’s definition of the service, the other is the app’s runtime config.

Do I need daemon-reload after editing a service file?

Yes. systemd caches unit files at boot, so after editing a .service file you must run sudo systemctl daemon-reload before restarting, or the service restarts with the old definition. Recent systemd versions print a warning reminding you when a unit file changed on disk but was not reloaded.

Why did my service file change not take effect?

Almost certainly because you ran systemctl restart without daemon-reload first. Restart uses systemd’s cached copy of the unit file, not the edited one on disk. Run sudo systemctl daemon-reload to load your edit, then sudo systemctl restart <service> to launch under the new definition.

What does systemctl reload-or-restart do?

It reloads the service if the service supports reloading, and restarts it if it does not. It is a safe choice when you are unsure whether a service can reload its config without a full restart, so you get the zero-downtime path where available and a clean restart where it is not.