macOS - Data Collection & Auditing - Get Automox macOS Softwareupdate Restart Logs

What the macOS softwareupdate restart log audit does

This Automox Worklet™ reads the softwareupdate restart logs that the Automox agent writes on macOS endpoints and prints the most recent entries to your Automox Activity Log. The Worklet targets two files the agent maintains under /var/log/amagent/: restart.log (standard output from softwareupdate restart activity) and restart.err (error output from the same activity). The audit is read-only. Nothing on the endpoint is modified, no log files are rotated, and no softwareupdate state is touched.

The Worklet exposes a desired_line_count input (default 20) so you can control how much log content lands in the Activity Log on each run. A smaller line count keeps output scannable when you audit the entire fleet on a recurring policy. A larger value gives you depth when you are chasing a specific endpoint that keeps stalling on softwareupdate.

Output is grouped under labeled headers (==========/var/log/amagent/restart.log========== and ==========/var/log/amagent/restart.err==========) so an operator reading the Activity Log can tell which file each block of lines came from. Empty files are reported explicitly so you can distinguish a quiet endpoint from a missing log.

Why audit softwareupdate restart logs across your Mac fleet

When a Mac silently fails a softwareupdate-driven reboot, the symptom often shows up days later as a CVE the patch dashboard claims is resolved but the endpoint still reports as vulnerable. The Automox agent already captures the relevant evidence locally in /var/log/amagent/restart.log and restart.err, but you have to SSH into the endpoint to read it. Reaching one laptop at a time does not scale when you are auditing dozens or hundreds of Macs.

Running this Worklet on a recurring data-collection policy lifts those log entries into the Automox console for every Mac in scope. You move from "patch state unknown on N endpoints" to a per-endpoint Activity Log that shows exactly what the agent observed during the last softwareupdate restart attempt, including any non-zero exit conditions written to restart.err. That trail also gives you audit evidence to attach to change tickets or compliance reviews.

How the restart log audit works

1. Evaluation phase: The evaluation script checks that both /var/log/amagent/restart.log and /var/log/amagent/restart.err exist. If either file is missing, the endpoint is reported as ineligible and the audit is skipped. If both files exist, the script tests each with -s; when either file is greater than 0 bytes the endpoint is flagged for remediation. Macs whose restart logs are both present and empty return compliant, which keeps Activity Log noise down on endpoints that have nothing new to report.

2. Remediation phase: The remediation script tails the last desired_line_count entries from /var/log/amagent/restart.log, prints a section header, then tails the same depth from /var/log/amagent/restart.err. If either file exists but is empty, the script reports it as empty rather than skipping the section, so the operator can distinguish "no events" from "file missing." The audit is read-only and does not modify either log.

Restart log audit requirements

• macOS endpoint with the Automox agent installed and writing softwareupdate restart logs to /var/log/amagent/

• Both /var/log/amagent/restart.log and /var/log/amagent/restart.err present on the endpoint (the evaluation exits without remediation if either is missing)

• Standard macOS shell utilities available on the endpoint: bash, tail, and cat (all present by default)

• desired_line_count parameter set on the policy (default 20; the remediation script falls back to 20 if the variable is empty)

Expected Activity Log output after the audit

After the Worklet runs, the Activity Log entry for each endpoint contains two labeled sections separated by the header lines ==========/var/log/amagent/restart.log========== and ==========/var/log/amagent/restart.err==========. Each section holds the last desired_line_count lines from the matching file, or a short message stating the file is empty. Healthy endpoints typically show restart.log entries indicating that the post-patch reboot was issued and observed, paired with a quiet restart.err.

Endpoints stuck on a softwareupdate restart show their evidence in restart.err. Cross-reference the timestamps of any error entries against the timeline of recent softwareupdate-driven patches in the Automox console to identify the patch attempt that triggered the failure. For ongoing visibility, schedule the Worklet on a daily or weekly cadence so the Activity Log accumulates a rolling record of restart outcomes across your Mac fleet.