Linux
View all Worklets
LinuxLinux

Linux - Forensics - Get Automox Agent Log (Amagent.log)

Retrieve Automox Agent logs from Linux endpoints for forensic review without opening an SSH session

Worklet Details

What the Linux Automox Agent log retriever does

This Automox Worklet™ reads the Automox Agent log on a Linux endpoint at /var/log/amagent/amagent.log and prints the requested portion to standard output. Automox captures that output and stores it as the Worklet activity record for the policy run, so the log lines appear in the console alongside the exit code without an admin opening an SSH session to the host.

The remediation script defines four functions (mode1 through mode4) and dispatches to one of them based on the worklet_mode variable. Mode 1 returns the last $desired_line_count lines (default 100) via tail and is the default for quick triage. Mode 2 returns the entire file with cat. Mode 3 returns every entry from a chosen date by piping the file through grep "$desired_date". Mode 4 returns the last $desired_line_count lines from a chosen date by combining grep and tail. Dates use the yyyy/mm/dd format that amagent.log already writes into each line, so the filter matches without reformatting.

Why pull Automox Agent logs from the console

When a Linux endpoint stops checking in, fails a patch run, or reports an unexpected exit code, the answer is usually in amagent.log. The log records agent startup, scheduler decisions, command runs, and the stderr from any Worklet that exited non-zero. Reading it directly tells you whether the agent saw the policy, whether it ran the script, and what the script returned.

Running this Worklet as a FixNow against a single Linux endpoint, or scheduling it against a Linux server or workstation group, pulls /var/log/amagent/amagent.log directly into the Automox Activity Log. A support engineer reads the diagnostic lines from the console instead of cutting an SSH ticket to a host that may be on a private subnet, behind a jump box, or on a remote workstation that never hits the corporate VPN.

How amagent.log retrieval works

  1. Evaluation phase: The script tests for /var/log/amagent/amagent.log with [[ -f /var/log/amagent/amagent.log ]]. When the file exists the endpoint is flagged non-compliant with exit 1 and remediation is scheduled. When the file is missing the Worklet exits 0, which prevents the policy from churning on hosts where the agent has never written a log. Because the check is presence-only, an endpoint with an existing amagent.log will flag for remediation on every scheduled run.

  2. Remediation phase: The remediation script reads the worklet_mode and desired_date variables, then dispatches to one of four paths. Mode 1 runs tail -n "$desired_line_count" /var/log/amagent/amagent.log. Mode 2 runs cat /var/log/amagent/amagent.log. Mode 3 runs grep "$desired_date" /var/log/amagent/amagent.log. Mode 4 runs grep "$desired_date" /var/log/amagent/amagent.log | tail -n "$desired_line_count". Output is written to stdout; the Automox Agent captures stdout as the activity record and ships it back to the Automox console for the policy run.

amagent.log retrieval requirements

  • Linux endpoint with a bash-compatible shell and the standard coreutils (tail, cat, grep)

  • Automox Agent installed and writing to /var/log/amagent/amagent.log (the default location for the agent package)

  • Read access to /var/log/amagent/amagent.log; the Worklet runs as root by default, which already satisfies the permission requirement

  • Set the worklet_mode variable in remediation.sh to 1, 2, 3, or 4 according to which retrieval path the policy run should take

  • Adjust desired_line_count (default 100) if Mode 1 or Mode 4 should return a different number of lines

  • For Mode 3 or Mode 4, uncomment and set desired_date to a yyyy/mm/dd string (for example 2026/05/19) that matches the date format amagent.log writes in each line. When desired_date is empty in Mode 3 or Mode 4, the Worklet exits 1 with a stderr message

  • Activity Log retention long enough to view the policy run output; very large logs from Mode 2 can exceed activity-output size limits, so prefer Mode 3 or Mode 4 when targeting a narrow window

Expected output in the Activity Log

After the Worklet runs, the chosen slice of amagent.log appears in the Automox console under the endpoint's policy activity. Open the run in the console and scroll the activity panel to see the captured lines: agent startup banners, scheduler check-ins, command dispatches, and any stderr from prior Worklets that exited non-zero. The Worklet exits 0 when the selected mode reads the file successfully, and exits 1 when worklet_mode is unset or invalid, or when Mode 3 or Mode 4 runs with an empty desired_date.

Validate by running tail -n 5 /var/log/amagent/amagent.log on the host and confirming the last lines match the activity output from Mode 1. For a forensic capture, save the activity output alongside the Automox policy run ID; the run ID, the endpoint ID, and the retrieved log range together form a reproducible chain of custody. When the activity output is truncated, rerun with a narrower date filter (Mode 3 with a single day, or Mode 4 with a date plus the line cap) to pull a smaller slice that fits inside the activity record.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets