216

I have a service that stopped suddenly. I tried to restart that service but failed and was asked to run: systemctl daemon-reload.

What does it exactly do? What is a daemon-reload?

Improve this question
0

2 Answers 2

Reset to default
141

man systemctl says:

daemon-reload

Reload systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the entire dependency tree. While the daemon is being reloaded, all sockets systemd listens on behalf of user configuration will stay accessible.

This command should not be confused with the reload command.

So, it's a "soft" reload, essentially; taking changed configurations from filesystem and regenerating dependency trees.

Consequently, systemd.generator states:

Generators are small binaries that live in /usr/lib/systemd/user-generators/ and other directories listed above. systemd(1) will execute those binaries very early at bootup and at configuration reload time — before unit files are loaded. Generators can dynamically generate unit files or create symbolic links to unit files to add additional dependencies, thus extending or overriding existing definitions. Their main purpose is to convert configuration files that are not native unit files dynamically into native unit files.

Generators are loaded from a set of paths determined during compilation, listed above. System and user generators are loaded from directories with names ending in system-generators/ and user-generators/, respectively. Generators found in directories listed earlier override the ones with the same name in directories lower in the list. A symlink to /dev/null or an empty file can be used to mask a generator, thereby preventing it from running. Please note that the order of the two directories with the highest priority is reversed with respect to the unit load path and generators in /run overwrite those in /etc.

After installing new generators or updating the configuration, systemctl daemon-reload may be executed. This will delete the previous configuration created by generators, re-run all generators, and cause systemd to reload units from disk. See systemctl(1) for more information.

Improve this answer
4
  • I am wondering why would one want to put this in a daily cron job see github.com/cri-o/cri-o/issues/2584 . he claims it is an overflow issue in systemd github.com/systemd/systemd/issues/11809 I would like to understand why it is needed and why it happened Commented Mar 25, 2020 at 11:07
  • 1
    I haven't looked into this in great detail, I could only speculate that the idea there is to try to force a "soft reload" using cron. I'm not sure if that's necessary, or how effective that is. The bug you linked to is shown to have been fixed. So, maybe they use older version of systemd. Again, merely speculating. You could try asking a new question with those references and a pointer to this question perhaps. Commented Mar 26, 2020 at 22:50
  • 1
    I'm wondering if it would be okay to always automatically systemctl daemon-reload run when inotify detects that some config file has been modified... Commented Jan 23, 2021 at 15:56
  • 2
    @MikkoRantalainen It is conceivable that you sometimes you might need the ability to change two or more service files and have the changes take effect together as a single, "atomic" operation. With the inotify scheme you propose, that becomes impossible. So you would need a way to opt out of the inotify detection when necessary. Commented Aug 22, 2023 at 6:11
28

If you change /lib/systemd/system/<servicename>.service and restart via

systemctl restart <servicename>.service

it will not load the new settings unless you do a systemctl daemon-reload. Instead, it will just restart the old cached settings with no changes.

This has burned us many times. People just restart service but forget that it does not reload the changes.

Alternatively, you can also reboot the entire system and the newly rebooted system will also read the new configurations for the service.

Improve this answer
3
  • 3
    This is the kind of concise and direct answer I would expect to find; more useful to me than a copy-paste from the manual. Commented Aug 11, 2024 at 1:25
  • 2
    You should NEVER change files in /lib/systemd/system! That path is reserved for package installed units systemctl edit creates local overrides in /etc/systemd/system/servicename.override.d/servicename: /etc is where machine/admin conf should go! If you are not overriding partly, you can pass --full to edit, and it will create the file /etc/systemd/system/servicename, that masks the one in lib. If you are changing files in /lib you are asking to be burnt anyway, as package update will silently overwrite your changes anyway, and decent postinstalls reloads the systemd daemon... Commented May 10 at 22:09
  • 1
    If you are arguing that you are editing non-package-installed unit files, then what in the hell those files are doing in /lib. Use /usr/local/lib/systemd for ones installed from other-than-repo sources (or built locally) FHS has its merits, alhough most distributions doesn't respect it as they should, and much less the admins... Commented May 10 at 22:14

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.