| Tested on | Red Hat Enterprise Linux 10.2 (Coughlan) |
|---|---|
| Package | systemd-257-23.el10_2.2.x86_64 |
| Applies to | RHEL 10.1 and later; Rocky Linux 10, AlmaLinux 10, and CentOS Stream 10 builds that ship a systemd soft-reboot capable of systemctl soft-reboot |
| Privilege | sudo or root to run systemctl soft-reboot; normal user can inspect SoftRebootsCount, boot_id, and PIDs |
| Scope | What soft reboot does, how to run systemctl soft-reboot, how to prove the kernel stayed up, when it helps after userspace updates, and when a full reboot is still required. Does not cover a full bootc image-mode workflow. |
| Related guides | systemctl command Linux boot, reboot and shutdown List systemd services with systemctl |
In this article we will use systemctl soft-reboot on RHEL to restart userspace while the running kernel stays up, then prove what survived with SoftRebootsCount, boot_id, uptime, and service PIDs.
Soft reboot support landed in RHEL 10.1. Red Hat positions it for userspace updates such as glibc, openssl, and dbus-broker, where you want processes to re-link to new libraries without a full firmware-to-kernel cycle. This walkthrough was captured on RHEL 10.2 with systemd 257.
systemctl soft-reboot drops interactive sessions, including SSH. Run it from a console you can reattach to, or plan to reconnect after userspace comes back. Do not treat soft reboot as a silent background refresh.
What Is a systemd Soft Reboot?
A soft reboot is a userspace-only restart. By default, systemd stops normal services and remaining processes, re-executes PID 1, then runs a normal userspace boot transaction. The kernel and hardware keep running.
NORMAL REBOOT
Applications
│
Services
│
systemd
│
Kernel ← restarted
│
Bootloader ← runs again
│
BIOS / UEFI ← runs again
│
Hardware
SOFT REBOOT
Applications ← restarted
│
Services ← restarted
│
systemd / PID 1 ← re-executed
──────────────────────────────
Kernel ← keeps running
Hardware ← keeps runningThat is why SoftRebootsCount can increase while /proc/sys/kernel/random/boot_id and kernel uptime stay tied to the same kernel instance.
Soft Reboot vs Normal Reboot
| Topic | Soft reboot (systemctl soft-reboot) |
Normal reboot (systemctl reboot) |
|---|---|---|
| Userspace | Restarts | Restarts |
| Kernel | Stays running | Restarts |
| Firmware / bootloader / initramfs | Skipped | Run again |
| Kernel boot ID | Same | New |
| SoftRebootsCount | Increments | Resets to 0 after a full boot |
/proc/uptime |
Continues | Resets |
| Typical use | Userspace library and service refresh | Kernel, firmware, initramfs, or hardware reset |
Check Whether Soft Reboot Is Available
Confirm systemd is new enough, that soft-reboot.target exists, and that SoftRebootsCount is readable. On this RHEL 10.2 host:
systemctl --versionsystemd 257 (257-23.el10_2.2-g009f2a8)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +IPE +SMACK +SECCOMP -GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVEsystemd 257 on RHEL 10.2 includes soft reboot. Next, confirm the target unit is present. The lines that matter are the description and the required soft-reboot service:
systemctl cat soft-reboot.target# /usr/lib/systemd/system/soft-reboot.target
...
[Unit]
Description=Reboot System Userspace
Requires=systemd-soft-reboot.serviceThen read SoftRebootsCount. It starts at 0 after a full boot and increases by one for each completed soft reboot:
systemctl show --value --property SoftRebootsCount0If the property or soft-reboot.target is missing, the host is too old for this workflow. Soft reboot is a RHEL 10.1+ feature.
Record the System State Before Soft Reboot
Before running the soft reboot, record a few values so you can prove afterward that only userspace restarted.
uname -r6.12.0-211.47.1.el10_2.x86_64Save this kernel version. It should be exactly the same after the soft reboot.
cat /proc/sys/kernel/random/boot_id441ecd50-c27c-4b8c-936d-0aea2271b183boot_id identifies the current kernel boot instance. It should stay the same.
cat /proc/uptime57792.91 133999.49The first field is seconds since this kernel booted. After soft reboot it should continue increasing instead of resetting.
SoftRebootsCount was still 0 (recorded in the availability section above). It should increase by one.
systemctl show sshd -p MainPID -p ActiveEnterTimestampMainPID=1247
ActiveEnterTimestamp=Sat 2026-09-19 06:54:35 ISTI also recorded the sshd PID. Because SSH is a userspace service, its PID should change when the service starts again.
Keep these values handy; we will compare them after the soft reboot.
Perform a Soft Reboot
Enqueue the userspace reboot. The command returns after the job is queued; your SSH session then drops when userspace stops:
sudo systemctl soft-rebootThis is equivalent to starting soft-reboot.target in replace-irreversibly mode. Wait for the host to accept SSH again, then reconnect.
On this lab the soft reboot completed around 22:58 IST. The SSH session closed as expected, then a new login worked once userspace was back.
Verify the Soft Reboot
Reconnect and run the same checks. Compare each result with the values you saved earlier.
uname -r6.12.0-211.47.1.el10_2.x86_64Same kernel release. Soft reboot did not load a different kernel.
cat /proc/sys/kernel/random/boot_id441ecd50-c27c-4b8c-936d-0aea2271b183Same boot ID. This is still the same kernel instance.
cat /proc/uptime58447.57 135703.86The uptime continued increasing from 57792.91 to 58447.57 instead of resetting to zero, confirming that the kernel never rebooted.
systemctl show --value --property SoftRebootsCount1The counter changed from 0 to 1, confirming that one soft reboot completed.
systemctl show sshd -p MainPID -p ActiveEnterTimestampMainPID=136463
ActiveEnterTimestamp=Sat 2026-09-19 22:58:06 ISTsshd came back under a new MainPID (1247 → 136463). The new ActiveEnterTimestamp matches the soft reboot window on this lab.
systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.No failed units after the soft reboot on this host. If any units are failed, check them before treating the soft reboot as successful.
Expected pattern after a successful soft reboot:
| Check | Expected result |
|---|---|
uname -r |
Same |
boot_id |
Same |
/proc/uptime |
Continues (does not reset) |
| SoftRebootsCount | Increases by 1 |
Service MainPID (for example sshd) |
Different |
systemctl --failed |
Clean, or only known failures |
What Happens During systemctl soft-reboot?
A soft reboot shuts down normal userspace services, restarts systemd as PID 1, and starts the normal userspace boot sequence again. It does this without restarting the kernel or passing through firmware, the bootloader, or initramfs.
Under the hood, systemctl soft-reboot starts soft-reboot.target, which requires systemd-soft-reboot.service. That service:
- Lets the normal shutdown path stop services that have DefaultDependencies
- Sends
SIGTERM, thenSIGKILL, to processes still running - Optionally switches root to
/run/nextroot/when that path exists (image-mode / staged root use case) - Re-executes the service manager (PID 1)
- Enqueues a new userspace boot transaction
See man systemd-soft-reboot.service on the host for the upstream wording.
What Survives a Soft Reboot?
The following kernel-level state remains in place across a normal soft reboot:
- Running kernel and loaded kernel modules
- Kernel uptime (
/proc/uptime) - Kernel boot ID (
/proc/sys/kernel/random/boot_id) - Kernel settings already applied through
/proc/sysor/sys - Hardware and firmware state
Normal application services are restarted. systemd does support advanced configurations where selected resources or services survive a soft reboot, but that is not the default behavior covered here.
Soft reboot is not a way to apply a new kernel, unload mismatched modules safely, or re-run firmware initialization.
What Is Restarted?
By default, userspace comes up again through the normal systemd boot transaction. In practice that includes:
- systemd units and services
- SSH and other network daemons
- NetworkManager and other userspace networking components
- D-Bus (
dbus-brokeron modern RHEL) - Applications and login sessions
Any process that still held an old glibc or openssl mapping is stopped and started again so it can open the new libraries.
When Should You Use Soft Reboot?
Use soft reboot when the change is userspace and you want a clean process restart without a full reboot cycle:
- After updating shared libraries such as
glibcoropenssl - After updating
dbus-brokeror other core userspace services - When many services need a coordinated restart after a large
dnfuserspace update
After dnf update, dnf needs-restarting can hint whether a reboot is needed. Soft reboot covers the userspace side; it does not replace a real reboot for kernel packages.
When Soft Reboot Is Not Enough
Plan a normal systemctl reboot (or equivalent) when you need:
- A new kernel package or kernel command line
- Kernel module changes that must match a different running kernel
- Kernel, kpatch, or firmware changes that require the full documented activation path
- initramfs rebuilds that must be exercised on the next boot path
- Hardware re-initialization
Red Hat’s RHEL 10.1 release notes call out the same limits: soft reboot does not apply kernel, kpatch, or firmware initialization changes.
systemctl soft-reboot vs reboot vs kexec
| Action | Userspace | Kernel | Firmware / bootloader |
|---|---|---|---|
systemctl soft-reboot |
Restarted | Same kernel continues | Skipped |
systemctl reboot |
Restarted | New boot of selected kernel | Normally runs |
systemctl kexec / kexec reboot |
Restarted | Switches to another kernel | Skipped |
Soft reboot is not a kexec reboot. Soft reboot leaves the current kernel running; kexec switches kernels. Use soft reboot when only userspace needs restarting. Use a normal reboot when you need the complete boot path, or use kexec only where your platform has a documented and tested kernel-switch workflow.
For ordinary service control without any reboot semantics, use systemctl restart unit instead. See List systemd services with systemctl and the systemctl command cheat sheet.
Measure Soft Reboot Downtime
From a second host, watch a simple probe while the target soft-reboots. Examples:
- Repeated
sshorncchecks against the management port - An HTTP health check if the host runs a web service
Compare the gap with a normal systemctl reboot on the same host. Soft reboot should skip firmware and kernel init, so the outage window is usually shorter, but exact seconds depend on how many services stop and start on your system. Measure on your own pair of hosts; do not copy someone else’s timing as a guarantee.
Soft Reboot with RHEL Image Mode / bootc
RHEL image mode also uses systemd soft reboot. In that case, /run/nextroot/ can be used to switch to a staged userspace image while keeping the current kernel running. Red Hat's bootc commands also provide --soft-reboot=auto and --soft-reboot=required. Kernel changes still require a full reboot. For the image-mode workflow, see Performing soft reboots to RHEL bootc images.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
systemctl: Unknown command verb soft-reboot |
systemd too old, or not RHEL 10.1+ soft-reboot capable | Check systemctl --version and systemctl cat soft-reboot.target; upgrade to a RHEL 10.1+ stream |
| SSH closes during soft reboot | Expected: userspace and sshd restart |
Reconnect after userspace returns; use console access if remote reconnect fails |
| SoftRebootsCount does not increase | Soft reboot did not complete, or you are looking at a different host/boot | Confirm the command was soft-reboot (not reboot); re-check after reconnect; SoftRebootsCount resets after a full boot |
| Updated kernel still not running | Soft reboot never loads a new kernel | Install the kernel package, then use systemctl reboot (or your platform’s full reboot path) |
| Service does not return after soft reboot | Unit failed during the new userspace boot transaction | Run systemctl --failed and journalctl -b -u unit; fix the unit, then systemctl start unit |
Summary
systemctl soft-reboot on RHEL 10.1+ restarts userspace while the same kernel keeps running. On this RHEL 10.2 lab, SoftRebootsCount moved from 0 to 1, sshd got a new MainPID, and uname -r, boot_id, and /proc/uptime stayed on the same kernel instance.
Use soft reboot after userspace updates such as glibc, openssl, or dbus-broker when you need processes to re-link cleanly. Use a normal reboot when the kernel, initramfs, firmware, or hardware path must change. Record SoftRebootsCount, boot_id, uptime, and a service PID before you run it, then reconnect and compare. That comparison is how you prove only userspace restarted.
References
Frequently Asked Questions
What does systemctl soft-reboot do?
It restarts normal userspace services, re-executes systemd as PID 1, and starts a new userspace boot transaction while the kernel and hardware keep running. It does not restart the kernel or walk firmware, the bootloader, or initramfs.
Does SSH disconnect during a soft reboot?
Yes. SSH and other userspace services restart, so interactive sessions drop. Reconnect after userspace is back.
Does soft reboot reset uptime?
No. /proc/uptime continues from the same kernel boot. SoftRebootsCount increases instead, which is how you count completed userspace soft reboots since the last full boot.
Can I use soft reboot after dnf update?
Yes for many userspace packages such as shared libraries and services. If the update includes a new kernel, kpatch, firmware, or initramfs change that must be exercised on a full boot path, schedule a normal reboot instead.
How do I prove the kernel was not restarted?
Compare uname -r, /proc/sys/kernel/random/boot_id, and /proc/uptime before and after. They should stay on the same kernel instance, while SoftRebootsCount increases and service MainPIDs change.
