macOS - Forensics - Get Automox Remote Control Log (rc-Module.log)

What the macOS Remote Control log retriever does

This Automox Worklet™ reads the Automox Remote Control daemon log on macOS endpoints and streams the selected entries to the Automox Activity Log. The log file lives at /usr/local/var/log/remotecontrold.log and is the macOS counterpart to the Windows rc-module.log retriever. The Worklet runs through the standard Automox Agent channel, so it works even when the Remote Control module itself is the component that is broken.

The remediation script supports four selectable modes driven by the worklet_mode variable. Mode 1 tails the last N lines (default 100) so you see the most recent session activity without flooding the Activity Log. Mode 2 dumps the entire remotecontrold.log for full-history forensics. Mode 3 filters by a target date using grep against each line of the log. Mode 4 chains a date filter into a tail count, returning the last N entries that match the date string.

The Worklet only reads remotecontrold.log and writes to standard output. It never modifies, rotates, or truncates the log file on the endpoint, so the policy is safe to schedule on a recurring cadence whenever a support engineer needs an evidence trail attached to a ticket.

Why pull remotecontrold.log from a remote endpoint

Remote Control failures are the case where you most need the logs and are least able to retrieve them by hand. The endpoint is offline from the support engineer's perspective, SSH is rarely an option on a managed Mac, and the user is the same person whose session just dropped. The remotecontrold.log on macOS records the Automox Remote Control daemon's session lifecycle, which is the diagnostic trail support uses to separate a connection failure from an authentication failure from a daemon-level error.

Running this Worklet as a FixNow against the affected Mac, or scoping it to an endpoint group when several users report dropped sessions, returns the remotecontrold.log slice directly to the Automox Activity Log where the support ticket already lives. The retrieval flow skips the user-upload step entirely, which matters most when the same user whose session just dropped is the one being asked for the file.

How remotecontrold.log retrieval works on macOS

1. Evaluation phase: The shell script tests for /usr/local/var/log/remotecontrold.log with [ -f ]. If the file is present, the script exits 1 and remediation is scheduled. If the file is missing, which usually means Remote Control was never enabled on that endpoint, the Worklet exits 0 without scheduling remediation so the policy does not generate false-positive failures across the fleet.

2. Remediation phase: The script branches on worklet_mode (1–4). Mode 1 runs tail -n $desired_line_count /usr/local/var/log/remotecontrold.log. Mode 2 runs cat against the full log. Mode 3 runs grep "$desired_date" against the log to return every line containing that date string. Mode 4 chains grep "$desired_date" | tail -n $desired_line_count to return the last N matching entries. Output goes to stdout, which the Automox Agent captures into the Activity Log against the run identifier. Modes 3 and 4 exit 1 when desired_date is empty; an invalid worklet_mode value also exits 1. All other paths exit 0.

macOS Remote Control log retrieval requirements

• macOS endpoint running the Automox Agent with the Remote Control module enabled; the log path is /usr/local/var/log/remotecontrold.log

• Automox Agent root context (the default agent privilege level satisfies this; no additional sudo configuration is needed to read the remotecontrold log)

• Set worklet_mode (1, 2, 3, or 4) in remediation.sh to select last-N, full-log, date-filter, or date-plus-tail output

• Set desired_line_count (integer, default 100) when using mode 1 or mode 4 to control how many recent entries to return

• Set desired_date (recommended format yyyy-mm-dd to match the log timestamp prefix) and uncomment the variable when using mode 3 or mode 4; the value is grep-matched literally against each log line

• Automox FixNow is supported, so you can trigger the policy ad-hoc against a single endpoint while a support session is open rather than waiting for the next scheduled evaluation window

Expected Activity Log output and validation

After the Worklet runs, the Activity Log entry for the endpoint contains the selected slice of remotecontrold.log preceded by a banner line that names the active mode and the line count or date filter that was applied. Each captured line carries whatever the Remote Control daemon wrote at runtime, including the original timestamp, log level, and message body. That trail is what support reviews to determine whether a failed session was a network reachability issue, an authentication problem, or a daemon-side error.

To validate the Worklet end-to-end, schedule it against a known-good endpoint with Remote Control enabled and confirm a non-empty Activity Log payload. Cross-check the captured timestamps against the time of the support session the engineer was investigating. For date-filtered runs, the count of returned lines should match the result of running grep "$desired_date" /usr/local/var/log/remotecontrold.log | wc -l on the endpoint directly. The Worklet does not modify remotecontrold.log, so repeat runs return identical output until new session activity appends to the file.