title: Reboot Required: Reboot-Required Status After Applying Updates
agents: linux, windows
catalog: os/misc
license: GPLv2
distribution: check_mk
description:
 Reports whether the monitored host needs a reboot to complete already-applied
 updates (e.g. a new kernel or core library that is installed but not yet running).
 The resulting service state when a reboot is required is configurable via the
 check's parameters ({OK}, {WARN}, or {CRIT}; default {WARN}) -- some admins use
 this signal purely for inspection without wanting it to alert. The underlying
 cause, where determinable, is always shown in the service output regardless of
 which state is configured.

 Detection is native per backend: {apt} checks {/var/run/reboot-required} (Ubuntu,
 with the affected packages as reason), then {needrestart -b -k}, then -- on Debian --
 the running kernel against the newest installed kernel of the same flavor in
 {/boot}; {dnf}/{yum} uses {dnf needs-restarting -r} or {needs-restarting -r};
 {zypper} uses {zypper needs-rebooting}. On every Linux system, these additional
 signals also report a reboot as required: the running kernel is no longer
 installed (its {/lib/modules} directory is gone), PID 1 still uses replaced
 libraries, core packages (glibc, systemd, dbus, microcode, firmware) were updated
 after the last boot on dpkg systems without Ubuntu's notifier, and a pending
 SELinux switch from/to disabled. On Windows: the Windows Update API, Component
 Based Servicing, pending update executables, a pending computer rename or domain
 join and the Configuration Manager client. {PendingFileRenameOperations} is
 shown separately: when it is the only signal, the service is {OK} by default
 (antivirus and installers set it routinely); its state is configurable. Every source that fired is listed as the reason;
 {unknown} only if nothing could be checked.

 Inside a container (Docker, Podman, LXC/LXD incl. Proxmox LXC), this always reports
 {not_applicable} ({OK}), with the container type as reason: a container shares the
 host's kernel, so a reboot-required signal about kernel/core-library updates
 inside it doesn't correspond to anything the container itself could act on.

item:
 None, this is a single service per host.

discovery:
 One service is created per host that reports a {system_updates_info} agent
 section -- the same host script that produces the {Pending Updates} service's
 data also produces this one, so both are always discovered together.

 A service is created even where the detected backend combination can't determine
 reboot-required status at all (reporting {unknown}) rather than not being
 discovered: this project's checks degrade per-feature, not by disappearing.
