Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 14. Performing soft reboots to RHEL bootc images

Apply updates to Red Hat Enterprise Linux bootc systems by performing a systemd soft reboot. This process reloads the operating system components without requiring a full hardware restart, ensuring faster deployment of changes and minimizing maintenance downtime.

14.1. Overview of performing soft reboots to RHEL bootc images
Copier lien

A soft reboot enables you to apply updates to Red Hat Enterprise Linux bootc images without performing a full hardware restart. This process minimizes downtime by reloading the operating system components while skipping the firmware initialization stage, ensuring faster application of changes.

A soft reboot primarily resolves common software-related problems with minimal risk. It is a standard troubleshooting step for issues such as:

  • Minor software glitches: A soft reboot resolves temporary errors that cause applications to freeze, crash, or misbehave.
  • Performance issues: Over time, open applications and background processes consume resources and slow down a system. A soft reboot clears these processes and refreshes the RAM, which can improve performance.
  • Network problems: For issues such as connectivity drops, a restart refreshes the network settings of the system.
  • Completing updates: Some system updates require a reboot to be finalized properly.

In a RHEL environment with systemd, a soft reboot restarts the user space while leaving the kernel and hardware running, which offers a significant benefits over a traditional, full reboot:

  • Reduced downtime: A soft reboot significantly reduces downtime because it skips the time-consuming boot process involving the BIOS/UEFI, boot loader, kernel, and initial RAM disk (initrd) . The system can quickly become responsive again, which is important for critical servers where minimizing downtime is essential.
  • Improved operational efficiency: For software and configuration changes that do not involve the kernel, you can use soft reboot to apply updates without a full system restart. This is particularly useful for containerized or image-based systems where a new root filesystem snapshot can activate instantly.

When invoked, the systemd-soft-reboot.service system service performs the following actions:

  • Sends a SIGTERM signal to any processes left running, without waiting for the processes to exit.
  • Continues with a SIGKILL signal to stop any process immediately.
  • If the /run/nextroot/ directory exists, which can be a regular directory, a directory mount point, or a symlink to either, it switches the file system root to it.
  • Re-runs the service manager from the root file system, which s updated, and enqueues a new boot transaction as a normal reboot.
  • Soft-reboot.target pulls in this service and performs a user space-only reboot operation.

14.2. Soft reboot behavior in package and image mode
Copier lien

A system running in image mode performs a soft reboot similar to as a package mode system that reboots only userspace. The difference is that you must build the updates to these packages and services first on the container image.

Soft reboot behavior in the package mode

In a package-based system, for example, a RHEL system that uses dnf, the soft reboot process involves shutting down and restarting systemd units to load new libraries and binaries. You can apply updates with minimal downtime. When you apply updates by using dnf in RHEL, systemd manages the behavior of the system during a soft reboot. The key units and expected behaviors are:

  • Service restarts: A soft reboot triggers systemd to stop and restart all running services. Updated packages for services, such as, the web servers or databases, apply the patch when the service restarts and reloads the new binaries.
  • Unit dependencies: systemd shuts down and starts units based on their defined dependencies and ordering. A soft reboot ensures these relationships are maintained, minimizing the chance of an improper shutdown sequence.
  • Processes and libraries: For updated shared libraries such as glibc or openssl, a running process continues to use the older, mapped library until it restarts. A soft reboot ensures that all processes stop and subsequently restart, causing them to link against the new version of the library.
  • Minimal downtime: A soft reboot is significantly faster than a hard reboot, because it does not reinitialize the kernel and hardware. It is effective for applying most userspace updates with minimal service interruption.
  • Command-line tools: The dnf-plugins-core package includes the needs-restarting tool. After running a dnf update, you can run dnf needs-restarting command to check if a soft reboot or specific service restart is required to apply the changes.

Userspace patching addresses security vulnerabilities and bugs in user-facing applications and shared libraries. When you apply patches, a soft reboot or process restart is required to load the new code. For example:

  • OpenSSL: Use case: Critical OpenSSL vulnerability discovered.

Problem: Applications that use OpenSSL, such as web servers, databases, and SSH daemons, remain exposed without a restart, continuing to use the vulnerable shared library.

Soft reboot solution: After performing a dnf update openssl, a soft reboot stops dependent processes. Systemd then restarts these services, automatically loading the new, patched libssl.so and libcrypto.so libraries, securing the system without a full machine reboot.

  • Glibc: Use case: A bug or security flaw is found in the GNU C Library (glibc).

Problem: Glibc is a foundational userspace component that nearly every program on the system depends on. A vulnerability in glibc impacts the entire system. Restarting one or two services is not enough, as many other processes will still be vulnerable.

Soft reboot solution: A dnf update glibc followed by a soft reboot is the most reliable way to ensure that all processes restart and re-link to the new glibc. This avoids the longer downtime of a full system reboot while guaranteeing the update is applied everywhere.

  • dbus-broker:

Use case: Updating the dbus-broker daemon for security or performance.

Problem: Dbus-broker is a critical system service. While updates are usually resilient, the sensitivity of the protocol requires restarting the broker and related services.

Soft reboot solution: A soft reboot restarts dbus-broker and all dependent services and applications, with systemd ensuring a clean shutdown and re-initialization.

Soft reboot behaviour in image mode for RHEL
In RHEL image mode (bootc), systemd performs a fast, userspace-only restart (soft reboot). Systemd-soft-reboot.service orchestrates this process, resetting the userspace while keeping the kernel and hardware running.

In an image-based system, you can manage updates in two ways:

  • Staged updates: The system fetches these updates from a container registry and installs them to an alternate, inactive partition or filesystem. It continues to run on the old version until it initiates a reboot.

A soft reboot switches the system to the newly staged, updated root filesystem and replaces the entire userspace at once. The system boots into the new, updated operating system image, and if issues appear, it retains the ability to roll back to the previous image on a subsequent boot.

  • Unstaged updates: Dynamic, in-place updates to the running userspace, such as configuration changes or restarting a single service. They do not involve creating and booting from a new, complete operating system image. A soft reboot reloads the current userspace from the same root file system. It does not pull or switch to a new, updated operating system image.

You can use it to reset the current software state without touching the kernel, which is useful for applying non-image-level changes or resolving userspace issues.

The systemd soft reboot mechanism is different from a kexec reboot. The kexec and kernel switching features are not available in the systemd soft reboot, as it only restarts the userspace, leaving the kernel untouched. This ensures continuity and avoids the potential complexities and inconsistencies that can arise from changing kernels without a hardware reset. An updated operating system image that includes a new kernel version requires a traditional, full reboot.

14.3. Initiating a soft reboot
Copier lien

Initiate a soft reboot on Red Hat Enterprise Linux to apply system updates without performing a full hardware restart. This method minimizes downtime by reloading the operating system components while skipping the firmware initialization process.

You can detect and prepare the system for a soft reboot when the system administrator runs bootc upgrade, bootc switch, or bootc rollback by using one of the two options:

  • --soft-reboot=auto: It automatically prepares the system if soft-reboot is possible and will not error out if the system is not capable of soft-reboot.
  • --soft-reboot=required: Automatically prepares the system if soft reboot is possible, but it errors out if the system is not capable of a soft reboot.

These options help you to manage when the limited downtime is required by stopping an --apply operation or informing you not to call reboot as bootc has not exited cleanly.

Prerequisites

  • You have information about the current status of the system.

Procedure

  1. Perform an update, switch, or rollback operation by using the bootc tool to stage the new container image. Otherwise, the soft runs again in the current userspace. 

    $ sudo bootc update --soft-reboot=required --apply

  2. Initiate a soft reboot, for example, while running bootc switch: 

    $ sudo bootc switch --soft-reboot=required --apply quay.io/test_rh/soft-reboot:1

Verification

  • Verify the soft reboot is completed: 

    $ systemctl show --value --property SoftRebootsCount
1

  • Check the new soft reboot:yes flag: 

    $ sudo bootc status --verbose

14.4. Known limitations of soft reboots
Copier lien

A soft reboot running in image mode has specific limitations because it is designed to update the userspace while leaving the kernel untouched.

The known limitations are: * Kernel and hardware remain unchanged: Any changes to the kernel, hardware drivers, or low-level kernel parameters are not applied during a soft reboot. For these updates to take effect, a full system reboot is necessary. Also, the kernel settings, for example, those configured by using sysctl, are not reset during a soft reboot. The system continues to use the same settings from before the reboot.

  • Firmware initialization: During a soft reboot, the operating system (OS) skips the firmware initialization. This is because the operating system retains control and directly restarts the kernel using a system call, instead of fully relinquishing control to the hardware. The kexec system call manages this process.
  • User responsibility for kernel module alignment with userspace changes: Even in image mode for RHEL, the user remains responsible for rebuilding and aligning custom kernel modules with userspace changes and a soft reboot does not bypass this. In fact, a soft reboot specifically keeps the running kernel, which can introduce compatibility issues if the userspace has been updated to expect a different kernel version or set of modules.
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début