Cron Job to Restart Automox Agent Nightly

What the nightly Automox agent restart does

This Automox Worklet™ installs a recurring cron job on Linux endpoints that restarts the Automox agent service every night at 3:30 AM. The Worklet reads the active crontab, looks for an entry that already restarts the agent, and writes a new entry only when one is missing. Endpoints that already have the schedule in place are left untouched, so the policy is safe to run on a recurring cadence across a mixed fleet.

The scheduled command includes a guard clause that prevents the restart from interrupting work in flight. The cron line runs ls /var/lib/amagent/execDir* &>/dev/null || service amagent restart, so the restart fires only when no execDir working directory is present. If the agent is mid-policy, the test short-circuits and the restart is skipped until the next nightly window.

Because the evaluation phase is idempotent, the Worklet can be scheduled to run as often as you like without churning the crontab. Drift caused by a re-imaged host, an admin clearing user crontabs, or a configuration management tool overwriting /var/spool/cron is corrected on the next policy run. If you need a different restart window, edit the cron line on a pilot host first, push a companion Worklet that removes the old 30 3 line, then redeploy this one with the new schedule.

Why enforce a nightly agent maintenance window

The Automox agent (amagent) is a long-lived daemon that accumulates memory, open file descriptors, and TLS connection state over weeks of uptime. On heavily loaded Linux hosts – container nodes, build servers, developer workstations left logged in for months – that drift eventually surfaces as stale check-ins, slow policy execution, or endpoints that appear offline in the console while the host itself is healthy. A scheduled service amagent restart on a quiet hour clears the daemon state, reloads the on-disk configuration, and lets the agent re-establish a clean session with the Automox console before the workday starts.

A cron entry that exists on the gold image is not the same as a cron entry that exists on every running host six months later. Configuration management tools can rewrite /var/spool/cron, an admin can clear the user crontab to fix something unrelated, and a host cloned from a stale template can come online without the schedule at all. The Worklet greps the active crontab for the literal service amagent restart string on every evaluation, so a missing schedule is detected and rewritten the next time the policy runs rather than surfacing weeks later as a stale-endpoint ticket.

How the nightly restart schedule is enforced

1. Evaluation phase: The Worklet runs crontab -l for the agent's effective user and greps for the literal string service amagent restart. If a matching entry is found, the endpoint is reported compliant and the policy exits cleanly. If no matching entry is found, the evaluation exits non-zero and Automox schedules remediation on the next policy window.

2. Remediation phase: The Worklet appends the line 30 3 * * * /bin/bash -c 'ls /var/lib/amagent/execDir* &>/dev/null || service amagent restart' to the active crontab. The cron daemon picks the new entry up on its next reload. Each night at 3:30 AM the guard clause checks /var/lib/amagent/ for in-flight execDir directories and only restarts amagent when the agent is idle, so a long-running remediation is never killed mid-step.

Cron-based agent restart requirements

• Linux endpoint with the Automox agent installed and reporting to the console (amagent service registered with systemd or sysvinit)

• Root or sudo privileges for the Automox agent (the default agent run context already meets this; required to write the crontab and to invoke service amagent restart)

• cron or cronie service enabled and running (systemctl is-enabled cron or systemctl is-enabled crond should return enabled)

• /bin/bash available at the standard path – the guard clause relies on bash short-circuit evaluation rather than POSIX /bin/sh

• No /etc/cron.allow or /etc/cron.deny restriction that prevents the agent's user from owning a crontab

• FixNow-compatible: trigger the Worklet from the device drawer in the console to install the cron entry on a single endpoint without waiting for the next policy window

Expected agent state after the cron job is installed

After the Worklet runs successfully, crontab -l on the endpoint shows the new schedule line and the Automox activity log records exit code 0. The agent continues normal operation immediately – no in-policy restart is performed during remediation itself. The change persists across reboots because cron reads the crontab from /var/spool/cron/crontabs/<user> on each scheduler tick, and the entry survives kernel and agent upgrades unless an administrator explicitly removes it.

To validate, run crontab -l | grep amagent and confirm the 30 3 * * * line is present. To dry-run the guard clause without waiting until 3:30 AM, copy the bash -c '...' portion to a shell and inspect the exit status – it should return 0 (skip restart) when /var/lib/amagent/execDir* exists and a non-zero status (proceed to restart) when no execDir is present. For an end-to-end test, temporarily change the cron minute and hour to a few minutes in the future on a pilot host, watch /var/log/syslog (or journalctl -u cron) for the cron invocation, then confirm amagent reconnects to the console within a minute of the restart. Once the schedule is in place, re-running this Worklet on a recurring policy keeps the cron entry pinned for every endpoint under Automox management, including hosts brought online after the original rollout.