17

Within CentOS-7 does a change in the options within /etc/systemd/system.conf of systemd require a reboot or will "systemctl daemon-reload" suffice?

Jeff Kubina
  • 427
  • 1
  • 4
  • 14

2 Answers2

25

No, daemon-reload will reload all unit files, not the configuration for systemd itself. However, # systemctl daemon-reexec will re-execute systemd and cause it to digest its new configuration in the process.

From the systemctl man page:

daemon-reexec
       Reexecute the systemd manager. This will serialize the manager
       state, reexecute the process and deserialize the state again. This
       command is of little use except for debugging and package upgrades.
       Sometimes, it might be helpful as a heavy-weight daemon-reload.
       While the daemon is being reexecuted, all sockets systemd listening
       on behalf of user configuration will stay accessible.

When the man page says daemon-reexec is useful for package upgrades, it in large part means that this command executes whatever new binaries there are and re-processes its configs. HOWEVER, the RPM that we use to upgrade systemd already contains a script to do this, so it is usually never needed in the case of a normal upgrade.

Or you can reboot. Either will do.

Spooler
  • 7,046
  • 18
  • 29
  • 3
    Note that the systemd RPM package includes a scriptlet that will already daemon-reexec when the package is upgraded, so you don't need to do this manually in that situation. – Michael Hampton Sep 28 '16 at 02:25
  • Excellent point. I'll update the answer. – Spooler Sep 28 '16 at 02:31
  • 1
    Just about the only thing that really needs a reboot anymore is the kernel. Most if not all services restart themselves (if they were already running) from within RPM scripts during upgrade using `systemctl try-restart`. – Michael Hampton Sep 28 '16 at 02:45
  • 2
    @MichaelHampton it is really a little more tricky: not only kernel, but also libc (and, sometime, device-mapper userland also) upgrades require a full reboot. Sure, you can pin-point and restart each affected services, but as basically *all* services are linked against libc, well, it is generally faster to reboot... – shodanshok Sep 28 '16 at 07:37
  • @Spooler - What do you mean by unit files? Do you mean files associated with `systemd`? – Motivated Feb 03 '19 at 03:31
  • @MichaelHampton - Does the scriptlet execute for all systems that is based on a RPM or is it limited to RedHat and CentOS? – Motivated Feb 03 '19 at 03:33
  • @shodanshok - Do you mean to say that `systemctl daemon-reexec is not sufficient to restart libc services? – Motivated Feb 03 '19 at 03:35
  • @MichaelHampton - What is the difference between `systemctl daemon-reexec` and `systemctl try-restart`? Additionally, do either result in processes being disrupted if they are in the middle of processing requests? – Motivated Feb 03 '19 at 03:39
  • @Motivated These are two completely different and unrelated actions. Please see first the descriptions in the man page. Then come back with more specific questions. – Michael Hampton Feb 03 '19 at 04:39
  • @MichaelHampton - Yes i did refer to the man page. It isn't clear as to the execution of the scriptlet int that if it is limited to RedHat and CentOS. – Motivated Feb 03 '19 at 05:00
  • 1
    @Motivated `libc` is not a service, rather the GNU C Library, which is linked by almost all linux executable. So, after a `libc` upgrade, you should restart any running program/process; the easier method is to reboot the machine. – shodanshok Feb 03 '19 at 08:11
  • 1
    @Motivated The answer is speaking of scripts in RPM packages, which are used by Red Hat derived distributions, but not by Debian derived distributions. These use different packaging methods, but also call systemctl to restart services or systemd itself. – Michael Hampton Feb 03 '19 at 14:45
0

Had a good look at getting this working, you need to restart the services as well on the server :(

First the command above:

systemctl daemon-reexec

then:

systemctl system.slice restart

Once done, its done, but am wondering about the overhead of this running all the time.

Steve
  • 1