1

This question is about RedHat 7/8/9 alike.

After applying most updates, it is enough to restart the affected services.

RedHat provides the tracer tool to identify exactly what needs to be rebooted. It produces output similar to the following:

You should restart:
  * Some applications using:
      systemctl restart chronyd
      systemctl restart firewalld
      systemctl restart mariadb
      systemctl restart polkit
      systemctl restart postfix
      systemctl restart rngd
      systemctl restart rsyslog
      systemctl restart sshd
      systemctl restart sssd
      systemctl restart systemd-journald
      systemctl restart systemd-logind
      systemctl restart systemd-udevd
      systemctl restart tuned
      systemctl restart vmtoolsd

  * These applications rebooting your computer:
      dbus
      kernel
      systemd

My understanding is that only kernel updates (without ksplice) should require a reboot.

How do I restart systemd and dbus without a reboot?

I already tried

systemctl daemon-reexec

To restart the PID-1 process.

But after tracer -a still reports that systemd "requires rebooting your computer".

For dbus, I don't even know where to start looking.

Improve this question
2
  • You don't actually need to reboot, although you are strongly recommended to do so at the earliest convenient time (schedule some downtime to reboot, or try to time upgrades around your existing maintenance schedule). The old versions of systemd and dbus will continue to run until the machine is rebooted. same for the kernel.
    – cas
    Mar 30 at 2:25
  • @cas Of course. Most of the time that works fine. I have seen cases where (for ordinary RPMs, like httpd) this does lead to a crash when some libraries on disk no longer match the ones in memory. Doesn't happen very often, but I try to make sure everything that needs to be restarted is restarted as early as possible, while reducing the impact on my system uptimes.
    – Kevin Keane
    Mar 31 at 5:40

2 Answers 2

Reset to default
2

systemctl daemon-reexec is the command to restart systemd. Keep in mind that PID 1 is not the only instance of systemd, however – each user with an interactive logon session has their own per-user instance as well, which they can restart using systemctl --user daemon-reexec. (Those instances are managed as user@*.service; related term: "linger".)

It is true that technically dbus-daemon can be restarted without a reboot, as it is just a userspace service, managed by systemd as dbus.service. In practice, however, it's not really recommended as doing so can cause many other services to unexpectedly exit due to losing connection to their IPC bus.

It's usually safe to keep an old version of dbus-daemon running, as it does not load any additional libraries or modules on the fly (everything it needs is loaded by ld.so on start). In contrast, httpd does load modules dynamically, which is what makes it crash in those situations.

Improve this answer
5
  • Thank you! Looks like updating without rebooting is a very complicated matter, then.
    – Kevin Keane
    Apr 13 at 6:08
  • Digging a bit deeper, I found that daemon-reexec does not do what one would expect it to do. The man page basically says that it is rarely useful. It does does not restart PID 1, but rather seems to take over the existing PID 1. ps -fp 1 will still show the original start date. That is probably why tracer -a does not recognize that systemd was restarted. In addition, it appears that systemd daemon-reexec can cause problems at least with containers. See access.redhat.com/discussions/4710031 (login required) for a discussion.
    – Kevin Keane
    May 7 at 9:13
  • @KevinKeane: That's still as good as "restarting PID 1", as an exec() loads a completely new executable image and starts it from scratch, regardless of whether it's done after fork or not. (Many services use the same mechanism to implement a "graceful restart" by exec'ing a new version of themselves in-place, but for PID 1 it's the only possible option as you would immediately get a kernel panic if the process exited.)
    – u1686_grawity
    May 7 at 9:16
  • Agreed, I understand why it is done that way. It would also be essentially impossible to get the PID 1 back without modifications to the kernel itself. Unfortunately, it is not exactly the same. In particular, the process will not reflect the date it was restarted. There are probably other subtle differences related to memory management etc. The bottom line is that tracer does not recognize the process as restarted.
    – Kevin Keane
    May 8 at 10:09
  • As far as I know, there aren't any differences related to memory management (fork/vfork/clone is where the weird stuff happens, while exec is where everything is reset clean, just as when starting a new process), only open file descriptors are inherited across exec – which systemd needs to retain deliberately in any case.
    – u1686_grawity
    May 8 at 10:22
0

This should ordinarily be a comment to elaborate on the excellent answer from @user1686 . I am making it a full answer to be able to copy some relevant notes from a URL.

After seeing @user1686's answer, I also found this: https://access.redhat.com/solutions/27943

Here is a (somewhat, subject to change) complete list of the packages that require a reboot. The list applies to RHEL 5/6/7, but is likely similar in RHEL 8 and 9.

kernel
kernel-PAE
kernel-rt
kernel-smp
kernel-xen
linux-firmware
*-firmware-*
dbus
glibc
hal
systemd
udev
gnutls
openssl-libs

Also:

This doesn't mean it is strictly required to reboot the system immediately after updating these packages.

Typically, it is sufficient to restart services after applying a non-security glibc erratum

The article provides more details, which all amount to "you should restart any service that depends on something that was updated". That is, of course, nearly every service at all.

So: you can indeed avoid a reboot if the kernel was not updated, but you will have to restart nearly every service instead.

The kernel itself can also be updated without a reboot by using kpatch in RHEL 7.7 and later, 8.1 and later, and RHEL 9.

Details are here: https://www.redhat.com/sysadmin/kernel-live-patching-linux

The instructions vary for RHEL 7, RHEL 8 and RHEL 9. For RHEL 8 and 9:

dnf install kpatch kpatch-dnf
dnf kpatch auto
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .