Linux - Configuration - Restart After Set Days

What the restart scheduling Worklet does

This Automox Worklet™ monitors endpoint uptime and automatically schedules a restart once a Linux endpoint exceeds a configurable number of days online. The Worklet calculates uptime in seconds from /proc/uptime and compares it against an administrator-defined threshold stored in the DayCounter variable.

The Worklet executes across Linux distributions including Ubuntu 20.04, RHEL 7, CentOS 7, AlmaLinux 9.1, and Fedora 36. When the endpoint's uptime in days meets or exceeds the configured threshold, the remediation phase schedules a reboot using the shutdown command with a one-minute delay to allow graceful service termination.

When the endpoint's uptime meets or exceeds the configured threshold, the remediation phase schedules a reboot with a one-minute delay to allow graceful service termination.

Why enforce periodic Linux restarts

Periodic restarts are essential for maintaining system stability, applying kernel updates, and refreshing system memory. Long-running Linux endpoints can accumulate memory leaks, orphaned processes, and stale file handles that degrade performance over time.

Many security frameworks and compliance standards require regular endpoint reboots to clear temporary credentials, maintain critical patches activate, and reset system state. Automating restart scheduling maintains consistent policy enforcement across your infrastructure without requiring manual intervention or maintenance windows.

This Worklet saves IT operations teams time by eliminating manual uptime tracking and reducing the risk of forgotten endpoints running indefinitely without restarts.

How uptime monitoring and restart scheduling works

1. Evaluation phase: The Worklet reads the current system uptime from /proc/uptime, extracts the uptime in seconds, converts it to days, and compares the result against the DayCounter variable. If uptime is less than the threshold, the evaluation exits successfully and no remediation is scheduled. If the threshold is met or exceeded, the evaluation exits with status 1 to trigger remediation.

2. Remediation phase: When triggered, the Worklet verifies the DayCounter variable is defined and then executes shutdown -r +1 to schedule a reboot one minute in the future. This delay allows running services and applications time to shut down gracefully.

Restart scheduling requirements

• Linux operating system: Ubuntu 20.04, RHEL 7, CentOS 7, AlmaLinux 9.1, Fedora 36, or equivalent distributions

• DayCounter variable must be defined before Worklet execution. Set this to an integer representing the maximum uptime in days (for example, 30 for a 30-day restart cycle)

• Standard system utilities available: grep, date, and shutdown commands

• Root or administrative privileges to schedule system restarts

• Access to /proc/uptime for reading system uptime information

Expected endpoint restart behavior

After the Worklet runs, endpoints meeting the uptime threshold will have a scheduled restart queued for one minute in the future. Connected users will see a shutdown notification message informing them of the pending restart.

The endpoint will display the countdown time and reboot on schedule. Any unsaved work should be completed before the restart occurs. Once the restart completes, the uptime counter resets to zero, and the cycle begins anew. Endpoints with uptime below the configured threshold will show a status message indicating no restart is required, and the Worklet will not trigger remediation.

How to validate restart after set days changes

1. Run this Worklet on a pilot Linux endpoint and review evaluation output for restart after set days.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as function, exit, errMessage.

4. Validate remediation effects from script operations such as function, errMessage, exit, then rerun evaluation for compliance.