Identify packages that will require a system reboot after an update

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 5
  • Red Hat Enterprise Linux (RHEL) 6
  • Red Hat Enterprise Linux (RHEL) 7
  • Red Hat Enterprise Linux (RHEL) 8
  • Red Hat Enterprise Linux (RHEL) 9

Issue

  • How to identify packages which require system reboot?

Resolution

Red Hat recommends that systems be rebooted after installation of an updated package. This ensures that all processes and services benefit from updates to core libraries and services.

Such reboots do come at a cost to system uptime, however, which we know many customers are keen to avoid. This information outlines when a reboot is required, best practice for customers following updates, and guidance on particular package update scenarios.

  • Each of the following packages requires a reboot in order to be fully-utilized. This list is for informational use and subject to change at Red Hat's discretion.

    NOTE: Not all packages listed here are available in all versions of RHEL.

    • kernel
    • kernel-PAE
    • kernel-rt
    • kernel-smp
    • kernel-xen
    • linux-firmware
    • *-firmware-*
    • dbus
    • glibc
    • hal
    • systemd
    • udev
    • gnutls
    • openssl-libs
  • Beginning in RHEL 7, yum-utils includes the needs-restarting plug-in with support for the -r, --reboothint flag. This command will report whether a reboot will be needed.

    # needs-restarting -r
    
  • Package microcode_ctl applies the microcode upon update on the live system, unless it is known to have issues. Still, it's possible that the microcode isn't taken into account until applied early during the next boot, as part of the early CPIO archive prepended to the initramfs. It is hence recommended to reboot the system after microcode_ctl update.

  • For packages that provide a service (e.g. xen, bind, cronie, cups, ntp, openssh-server), restarting the service after updating the package is sufficient to make use of the updated binaries. Similarly to system reboots, Red Hat is aware that restarting services may also incur downtime for the provided service.

  • For packages that provide both services and daemons (e.g. dbus), restarting all daemons and services by bringing the system down to single user mode (runlevel 1), and back up to the previous runlevel, is the recommended best practice.

NOTE:

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 (i.e. RHBA rather than RHSA). The restarted services will immediately make use of the new glibc runtime. Until that time, such services will continue to use the earlier version of those libraries, having been loaded by the dynamic linker at service startup.

    Note that, depending on the nature of the bug being fixed, it may not be necessary to immediately restart the service.

    Disk space will continue to be consumed by the old runtimes until all packages referencing them close their open file descriptors, allowing the kernel to free the reserved storage.

  • This excludes any updates to packages which have an explicit or implicit dependency on kernel updates; in these cases, a reboot is still required to benefit from the updates to those packages.
  • Updates to security-sensitive libraries, such as openssl and gnutls, are especially important. Any services that depend on such libraries should be restarted to ensure that related errata are effectively used.

    In the case of updates to significant vulnerabilities, a full reboot is still the conservatively correct approach.

  • All errata pushed live to RHN after September 16 2015 for packages listed above will be tagged as "reboot_suggested" on RHN Classic Hosted and Red Hat Satellite 5.6/5.7, so customers can be aware and decide to boot systems after applying these errata.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments