Reboot System

What the Linux reboot trigger does

This Automox Worklet™ triggers a scheduled system reboot on Linux endpoints by invoking the shutdown utility with a restart flag and a configurable delay. The default delay is two minutes, which gives running services time to flush state, write logs, and broadcast a warning to logged-in sessions before init signals the kernel.

The remediation script runs shutdown -r [minutes] under the Automox agent context, so no interactive SSH session is required. You can edit the minutes argument to match a maintenance window: use now for an immediate restart, +5 for a five-minute warning, or a wall-clock time such as 23:00. The script also includes commented examples for shutdown -h now if you need to halt an endpoint instead of restarting it.

The Worklet runs across every Linux distribution Automox supports, including RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, SLES, Amazon Linux, and Oracle Linux. The shutdown binary ships with systemd on modern distributions and with sysvinit-utils on legacy ones, so no extra dependencies are required and the policy is safe to schedule against a mixed-distro fleet.

Why trigger reboots from the Automox policy

Linux endpoints accumulate pending-reboot state after kernel patches, glibc updates, systemd upgrades, and module replacements. On Debian and Ubuntu the signal is /var/run/reboot-required and the package list in /var/run/reboot-required.pkgs. On RHEL and CentOS, dnf needs-restarting -r returns exit code 1 when a restart is needed. Pending-reboot state means the patch is on disk but the live kernel and shared libraries are still the vulnerable versions, which is the most common cause of a CVE remediation showing applied in the patch report but still failing the next vulnerability scan.

Sequencing this Worklet after the patch policies that produced the pending-reboot state finishes the patch cycle without an SSH session per host. A maintenance window that covers 500 RHEL servers and 2,000 Ubuntu workstations becomes a single Automox policy run with a two-minute warning, instead of scripted shutdown -r calls across an inventory file. Logged-in users see the wall message and have time to save work, the agent performs the reboot, and the post-reboot evaluation reports the new kernel and updated libraries actually in memory.

How the scheduled reboot fires

1. Evaluation phase: The evaluation script signals that the endpoint is in scope for a restart by returning a non-zero exit code, which marks the endpoint non-compliant in the Automox console and queues remediation. Pair the Worklet with a pending-reboot detector such as a separate evaluation that checks for /var/run/reboot-required on Debian or Ubuntu, or runs dnf needs-restarting -r on RHEL family endpoints, when you want the reboot to fire only on endpoints that actually require one.

2. Remediation phase: The remediation script executes shutdown -r [minutes] with the configured delay value. The shutdown utility broadcasts a wall message to every active TTY and SSH session announcing the impending restart, denies new logins inside the final five minutes, and signals init (systemd on modern distributions, sysvinit on legacy) to enter runlevel 6. After the delay expires, the kernel cleanly umounts filesystems, syncs disks, and reboots. The Automox agent re-registers with the platform on the next boot, which closes the loop on the policy run.

Scheduled reboot requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, SLES, Amazon Linux, or Oracle Linux

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• The shutdown binary on PATH, typically /sbin/shutdown or /usr/sbin/shutdown, present by default in util-linux on every supported distribution

• Edit the minutes argument in remediation.sh to set the delay: 0 for immediate, +N for an N-minute warning, or HH:MM for a wall-clock time

• Schedule the policy inside an approved maintenance window so running workloads, container hosts, and database services are not interrupted mid-transaction

• Optional: chain this Worklet after a pending-reboot detector so endpoints without /var/run/reboot-required or with a clean dnf needs-restarting -r result are skipped

Expected state after the reboot fires

Once remediation runs, every active TTY and SSH session receives a wall broadcast that reads similar to "The system is going down for reboot at HH:MM". Logins are blocked inside the final five minutes of the countdown, and systemd begins stopping units in dependency order. When the delay expires, the kernel umounts mounted filesystems, syncs pending writes, and triggers a warm restart. The endpoint comes back on the new kernel and shared library set, which clears pending-reboot state and removes the patch from the next vulnerability scan.

Validate after the boot by checking that uptime reports a fresh restart with uptime --since, confirming the running kernel matches the installed kernel with uname -r against rpm -q kernel or dpkg-query -W linux-image-generic, and re-running the pending-reboot detector. On Debian and Ubuntu, /var/run/reboot-required should be absent. On RHEL family endpoints, dnf needs-restarting -r should exit 0 with the message "Reboot should not be necessary". For audit evidence, capture the last reboot output and the Automox policy run identifier and store them with the maintenance-window ticket.