HEALTH-CHECKER(8)

💖 NAME 💖

okay so this is the health-checker page, section 8 of the manual, bestie. it covers health-checker and health-checker.service, and their whole thing is checking that all the important services on a system actually came up correctly after an update and a reboot. like, vibe check for your boot process. 💅

✨ SYNOPSIS ✨

/usr/sbin/health-checker

/usr/sbin/health-checker --version

health-checker.service

🦋 DESCRIPTION 🦋

health-checker checks whether the system is coming up correctly during boot up. the behavior lowkey depends on whether the system is using systemd-boot/grub2-bls or legacy grub2. two paths, two whole vibes. 😭

with systemd-boot/grub2-bls, the bootloader picks the first available entry, and health-checker checks that the system has booted successfully. when any plugin fails, health-checker behaves depending on the entry that was booted:

• if it is a snapshot that has previously been booted successfully, then health-checker will try rebooting the system once more, and it will open an emergency shell if the system still fails to boot.
• if this is the first boot of a new snapshot, then the system will reboot a number of times (the count is configured in /etc/kernel/tries), checking the status each time. if the system still fails to boot, then health-checker marks the current entry as not working and reboots. the bootloader will pick the next available boot entry.

it is possible to disable health-checker automated rebooting by adding "health-checker-reboot=disabled" to the kernel cmdline. so if you're like "bestie pls no auto-reboot," that's the little switch. 👑

in case of an error and legacy grub2 is used, the remediation action depends on what happened before:

• if this is the first boot after a transactional update, an automatic rollback to the last known working snapshot is executed.
• if the snapshot was already rebooted successfully before, a reboot is tried.
• if this does not help, some services are shutdown and an admin has to repair the system.

if the boot was successful, the current snapshot is marked as known to be working. iconic, honestly. 🌈

plugins are used for performing the tests, and new plugins can be written. they are stored in the /usr/libexec/health-checker or /usr/local/libexec/health-checker (individual user plugins) directory and are executed either with the option check or stop.

• if called with "check", the plugin should verify that the service works and return 0, else 1.
• if one plugin returns "1", health-check will evaluate what to do.
• if neither a rollback or reboot is useful, all plugins will be called with the "stop" option. in this case, the plugins should shutdown the services as far as possible and useful.

bestie, this is the serious part: a plugin returning 1 kicks off the evaluation flow, and the stop path means services are being shut down as far as possible and useful. no cap, pay attention here. 🫶

🎀 TELEMETRY 🎀

if telem-record-gen(1) is installed, telemetry events are created additional to logging with syslog(3). so yes, the lore is being recorded. ✨

💜 SEE ALSO 💜

• transactional-update(8)

🌸 AUTHOR 🌸

Thorsten Kukuk <kukuk@suse.de>

k bye bestie, that's the whole page 💅🦋 — cute little sign-off from the footer: this was health-checker, dated 05/06/2026, and it ate fr fr. 🎀