Get Free Memory as Percentage

Reports free memory as a percentage of installed RAM on Linux endpoints for fleet-wide capacity reporting

Worklet Details

What the Linux memory audit Worklet does

This Automox Worklet™ reports free memory on each Linux endpoint as a percentage of installed RAM. The remediation script runs free | grep Mem | awk '{print $4/$2 * 100.0}', which reads the kernel's memory totals, divides the free column by the total column, and prints a single floating-point value to standard output. The Automox agent captures that value with the policy run, where it becomes a queryable signal alongside patch state and configuration drift.

The evaluation script always returns a non-zero exit code, which directs the Automox agent to run the remediation script on every endpoint in scope. The remediation script does not free memory, kill processes, or restart services. The remediation step is the report itself, designed to feed dashboards, saved views, and follow-up Automox policies that act on the reported value.

Because the Worklet returns one floating-point number per run, the payload stays small and the parsing logic on the reporting side stays trivial. A host with 8 GB total and 2 GB free returns 25.0; a host running near a memory ceiling returns a value in the single digits.

Why audit memory utilization at fleet scale

Memory exhaustion is one of the harder failure modes to diagnose on a Linux fleet. A long-running application starts to swap, page cache shrinks, the OOM killer fires on a service the runbook does not expect, and the on-call rotation gets paged for a symptom that started hours earlier. Without a fleet-wide percentage on hand, the only path to root cause is opening SSH sessions on individual hosts and reading top or vmstat under pressure.

Identifying memory-pressured Linux hosts usually means stitching together a monitoring stack, a CMDB, and an ad-hoc SSH audit script. This Worklet collects the same percentage directly through the Automox agent that already runs on every endpoint, so memory headroom becomes another field on the same record as patch compliance, OS version, and policy state. You can sort the fleet by free memory percentage, build a saved view of the bottom 10 hosts by headroom, or run the Worklet on-demand against a single host during an active incident.

How the Linux memory audit works

1. Evaluation phase: The evaluation script exits with a non-zero code on every endpoint in scope. This signals the Automox agent that the endpoint is non-compliant for reporting purposes and triggers the remediation step, which is where the measurement actually happens. The evaluation does not parse memory; it is the trigger that runs the reporter on every endpoint.

2. Remediation phase: The remediation script runs free | grep Mem | awk '{print $4/$2 * 100.0}'. The free command emits the kernel's memory accounting with column 2 holding total memory and column 4 holding free memory. awk divides free by total, multiplies by 100, and prints the result. The Automox agent captures the printed value with the policy run identifier.

Linux memory audit requirements

• Linux endpoint running any modern distribution (RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, SLES, Amazon Linux)
• Bash shell and the standard free utility from procps-ng, installed by default on every supported distribution
• awk and grep from coreutils for the percentage calculation
• No elevated privileges required; the Automox agent reads kernel memory statistics under its default service account
• Network reachability between the endpoint and the Automox console so the agent can report the captured value
• Awareness that free reports unallocated memory in column 4 rather than the often more useful MemAvailable figure from /proc/meminfo; on cache-heavy workloads the reported value will look lower than the headroom the kernel could actually reclaim

Expected memory audit output

Every run records a single floating-point percentage per endpoint. A host with 8192 MB total and 2048 MB free returns 25.0; a host running near a memory ceiling returns a value in the single digits. Automox stores the value with the policy run identifier, so you can chart utilization over time, filter the fleet by available memory, or build a saved view of the bottom 10 endpoints by headroom.

Validate the Worklet on a pilot host by running free interactively and dividing column 4 by column 2 by hand. Confirm the value matches what the Worklet reports in the Automox activity log. To exercise the alert path, apply an artificial memory load (for example, stress-ng --vm 2 --vm-bytes 80% --timeout 60s) and re-run the Worklet; the percentage should drop into the single digits while the load runs. Because the Worklet is FixNow compatible, you can also fire it on-demand against a single host during an active incident without waiting for the next scheduled policy run.