`systemctl daemon-reload` Is the Command You Need After Changing a Unit File When systemd Keeps Acting Like Your Edit Never Happened
A practical guide to `systemctl daemon-reload` for refreshing systemd after changing service unit files so your next restart uses the new definition instead of stale manager state.
Why this command matters: editing a systemd unit file does not automatically mean systemd has re-read it.
This catches people constantly. They edit a .service file, save it, restart the service, and then wonder why the old ExecStart, environment, or working directory behavior is still in effect. The reason is often simple: systemd’s manager state has not been reloaded.
The command
sudo systemctl daemon-reloadThis tells systemd to reload unit files and related manager configuration from disk.
After that, restart the service you changed:
sudo systemctl restart my-service
sudo systemctl status my-serviceThat sequence is what turns a unit-file edit into active runtime behavior.
When you should use it
Run daemon-reload after:
- changing a unit file in
/etc/systemd/system - updating an override with
systemctl edit - adding a new unit
- changing dependencies or restart policies
If the unit definition changed on disk, assume systemd needs to be told.
Why developers miss this
People assume service managers behave like hot-reloading app frameworks. systemd does not read your mind. Saving the file is not the same as reloading the manager state.
That is why the familiar confusion appears:
- “I changed
ExecStartbut it still runs the old command” - “I added an env file and nothing changed”
- “I updated the working directory and it is still wrong”
Often the missing step is just daemon-reload.
Final recommendation
If you changed a systemd unit and the service behaves as if your edit never happened, stop doubting your own eyes and reload the manager. systemctl daemon-reload is the step that many people forget and then lose time rediscovering.