Kill Open Process (macOS)

What the macOS process terminator does

This Automox Worklet™ terminates a named application process on macOS endpoints. The evaluation script always returns exit code 1, which schedules the remediation script to run on every policy execution. The remediation script reads a procName variable, looks up the process ID with pgrep -i, confirms the process is actually running, and sends a kill signal to the PID.

The Worklet is designed to be chained in front of another lifecycle action. The script header calls this out explicitly: drop it at the start of an installer policy so the target application is no longer holding open file handles when the installer copies the new application bundle into /Applications. Common use cases include Zoom, Google Chrome, Slack, Microsoft Teams, Adobe Acrobat Reader, Citrix Workspace, and any other macOS application that ships frequent in-place upgrades.

The procName variable in remediation.sh ships with the default value zoom.us, which matches the macOS process name that Zoom Workplace registers (note the literal dot in zoom.us, not the domain). Replace it with the exact process name as it appears in ps -axc or Activity Monitor before scheduling the policy. The kill command sends SIGTERM by default, which lets the application handle the signal and exit cleanly; switch to kill -9 inside the script when you need an unconditional SIGKILL for a hung or unresponsive process.

Why terminate processes before lifecycle actions

macOS installers fail silently when the target application is running. Drag-install packages cannot replace an open .app bundle, pkg installers leave the old binary in place when the running process has file handles open, and custom upgrade scripts return exit code 0 even though the new version never actually wrote to disk. The endpoint reports a successful patch and then keeps running the vulnerable build, which is exactly the gap a vulnerability scanner finds three weeks later. A pre-install kill step removes the file lock so the installer writes the new bundle on the first attempt.

Application upgrades on macOS fail quietly when a process still holds the bundle open, and a help desk cannot ask thousands of users to quit the app on cue. This Worklet runs kill against the resolved PID under the Automox elevated context on every Mac in scope, so the next Zoom, Chrome, or Slack upgrade lands on every endpoint rather than only the ones whose users happened to quit the app first. Chain it ahead of any install or repair Worklet that touches a locked binary.

How macOS process termination works

1. Evaluation phase: The evaluation.sh script returns exit 1 unconditionally. There is no live check of process state in evaluation; instead the policy is treated as always non-compliant so the remediation script runs on every Automox cycle. This keeps the Worklet predictable when used as a prerequisite step in a chained policy, because the kill attempt fires regardless of whether the process happens to be running at evaluation time.

2. Remediation phase: The remediation.sh script captures procID with pgrep -i "${procName}" for case-insensitive PID lookup, then runs pgrep -il zoom | awk '{ print $2 }' to verify the process name actually matches what is running. The script compares procTest to procName: if the names do not match, it echoes that the process is not running and exits 0. If they match, it runs kill "${procID}" and echoes a confirmation line that appears in the Automox activity log for that endpoint.

Process termination requirements

• macOS Workstation or Server endpoint with the Automox agent installed and reporting

• Bash and the standard BSD userland (pgrep, awk, kill) – all present by default on every supported macOS release

• Root or admin execution context for the agent, since the target process may be running under a different user

• Exact process name set in the procName variable in remediation.sh – match the name printed by ps -axc, not the .app bundle name (for example zoom.us, not Zoom.app)

• The pgrep -il zoom hard-coded check on line 42 should be updated to match the target process if you are not killing Zoom; otherwise the script will exit 0 for processes that do not contain 'zoom' in the name

• When chaining with an installer Worklet, schedule this Worklet first or include the kill logic at the top of the install script – Automox runs policies independently, so place the policies in the desired order on the endpoint group

Expected state after process termination

After remediation, the named process is no longer running on the endpoint. pgrep -i "${procName}" returns no output, Activity Monitor does not list the application under Process Name, and lsof | grep "${procName}" reports no remaining open file handles. A follow-on installer Worklet in the same policy chain is now free to write the new application bundle into /Applications without hitting a 'file in use' error. The Automox activity log captures either 'The process <name> isn't running on this device. Exiting.' or 'Killing <name>.' depending on the initial state, which gives the change-control reviewer a per-endpoint record of what happened.

Validate on a pilot endpoint by launching the target application, running this Worklet against the device manually with FixNow, and confirming the application disappears from Activity Monitor within a few seconds. Re-run the evaluation: it will still return exit 1 by design, which is expected behavior, not a failure. For audit evidence, export the Automox activity log filtered to this policy and store it with the corresponding installer-policy run identifier. The end user experience is an abrupt application close with no save prompt, so schedule the policy during a maintenance window when active work loss is acceptable, or pair it with a notification Worklet that warns the user a minute in advance.