Linux - Configuration - Restart After Set Days

What the Linux uptime restart enforcer does

This Automox Worklet™ enforces a maximum uptime policy on Linux endpoints. The Worklet reads the current uptime from /proc/uptime, converts the seconds value to whole days, and compares the result against the DayCounter variable that an administrator sets in the policy. Endpoints below the threshold are left alone. Endpoints at or above the threshold are flagged non-compliant and scheduled for a graceful reboot in the remediation phase.

Evaluation uses a simple grep -o '^[0-9]\+' /proc/uptime read paired with arithmetic in the date command to derive whole days from the kernel's uptime counter. The script exits 0 when the host is under the threshold and exits 1 with a message written through the errMessage helper when it is over, so the threshold breach surfaces in Automox activity logs rather than being swallowed.

Remediation reuses the same uptime read and the same comparison, then calls shutdown -r +1 to schedule a reboot one minute in the future. The one-minute delay gives running services, package managers mid-transaction, and any logged-in users a window to shut down cleanly before the kernel restarts.

Why enforce an uptime cap on Linux endpoints

Linux endpoints that run for months without a reboot accumulate problems an admin cannot see from the console. Kernel patches installed through yum update or apt upgrade stay queued against the running kernel until the next boot, leaving the host exposed even though the package database reports the fix as installed. Long-lived processes leak memory or hold stale file descriptors after a glibc or OpenSSL replacement. Compliance frameworks such as CIS Distribution Independent Linux and NIST 800-53 IA-5 expect a documented reboot cadence to clear temporary credentials and reapply hardened defaults.

Linux uptime accumulates silently. A patch policy lands kernel and glibc updates on disk, but the live kernel and shared libraries stay on the previous versions until the host reboots, and reboot decisions tend to slip into the next maintenance window indefinitely. Scheduling this Worklet against the Linux estate enforces the configured uptime threshold on every evaluation, so a build host that has been online for ninety days or an Ubuntu workstation that nobody has logged out of in a quarter is rebooted before the gap becomes an audit finding or a stalled patch cycle. The same policy run covers RHEL servers, Debian container hosts, and SLES jump boxes simultaneously.

How the uptime threshold check works

1. Evaluation phase: The script reads the first integer from /proc/uptime as UptimeInSeconds, converts to whole days through $(( UptimeInSeconds/3600/24 )), and compares against DayCounter. An unset DayCounter exits 0 with a no-op message. Under the threshold exits 0 with a compliant message. At or over the threshold writes the breach detail through errMessage to stderr and exits 1 to trigger remediation.

2. Remediation phase: The script re-reads /proc/uptime and re-applies the same day conversion to avoid a stale value from the evaluation pass. If DayCounter is unset, the script writes an error and exits 1 so the misconfiguration is visible. Otherwise it logs the current uptime in days and runs shutdown -r +1, which queues a reboot one minute out and broadcasts a wall message to any logged-in users.

Linux uptime policy requirements

• Linux endpoint running Ubuntu 20.04, RHEL 7, CentOS 7, AlmaLinux 9.1, Fedora 36, or an equivalent distribution that exposes /proc/uptime

• Set the DayCounter variable in both evaluation.sh and remediation.sh to the maximum allowed uptime in days. The two values must match. Common cadences are 7, 14, and 30 days.

• Standard system utilities available on PATH: grep, date, and shutdown from the systemd or sysvinit-utils package

• Root or sudo privileges to call shutdown -r (the default Automox agent context already meets this)

• Maintenance window or end user notification policy that tolerates a one-minute warning before reboot; pair with a Worklet that posts a longer-lead notice on user-facing workstations if required

Expected endpoint state after the restart

Endpoints above the threshold queue a reboot for one minute out and broadcast a wall notification to logged-in users before the kernel restarts. After the host comes back online, uptime resets to a value well below DayCounter, and the next evaluation reports the endpoint as compliant. Endpoints already below the threshold return a compliant message and exit 0 without triggering remediation.

Validate by running uptime -p or who -b on the endpoint after the Worklet runs. Both should reflect a boot time within the last few minutes. Capture the Automox activity log entry showing the breach message from the evaluation phase and the shutdown invocation from the remediation phase as audit evidence for the reboot cadence. Schedule the policy on a daily or weekly cadence so any host that drifts past the threshold is caught on the next run, not at the next manual sweep.