Linux - Configuration - Ensure the Crowdstrike Service is Running

What the CrowdStrike Falcon sensor verifier does

This Automox Worklet™ verifies that the CrowdStrike Falcon sensor is installed on the Linux endpoint and actively connected to the CrowdStrike cloud. The Worklet inspects /opt/CrowdStrike/falconctl to confirm the agent binary is present. It then runs falconctl -g --aid to read the agent ID, which is the canonical signal that the sensor is loaded and registered with the Falcon backend.

When the binary is present but the daemon is not active, the Worklet restarts falcon-sensor through the service command and falls back to systemctl start falcon-sensor on systemd-based distributions. After a short initialization window, the script re-checks the service state and exits non-zero when the sensor still fails to start. The evaluation is idempotent, so the policy is safe to schedule on a recurring cadence across mixed RHEL, CentOS, Rocky, Alma, Ubuntu, and Debian fleets.

Endpoints that do not have Falcon installed are skipped without remediation. The Worklet does not attempt to install the sensor itself, which keeps the policy scope tight and avoids unintended deployments on hosts excluded from the EDR rollout. Pair this Worklet with a separate install Worklet when coverage gaps need to close.

Why enforce continuous CrowdStrike Falcon coverage

Falcon is the detection and response control on the endpoint. When falcon-sensor stops, behavioral monitoring, IOC matching, and managed threat hunting go dark on that host. A debug session that ran systemctl stop falcon-sensor and never started it again, a kernel upgrade that outpaces the supported falcon-sensor kmod, or a cleanup script that disabled third-party agents during an image build all leave the daemon offline.

The longer the sensor stays down, the wider the blind spot in your SOC telemetry, and the larger the audit exposure under CIS Critical Security Control 10 or SOC 2 CC7.1. Run this Worklet across your RHEL, CentOS, Ubuntu, and Debian endpoints to evaluate the falcon-sensor service state and restart it where stopped, then keep it on a recurring schedule so the next pass closes the gap before it shows up in a control review.

How Falcon sensor verification works

1. Evaluation phase: The Worklet tests for /opt/CrowdStrike/falconctl to confirm the sensor is installed. When the binary exists, the script runs /opt/CrowdStrike/falconctl -g --aid and discards stdout. A zero exit from falconctl indicates the sensor is loaded with a valid agent ID, and the endpoint is reported compliant with exit code 0. A non-zero exit from falconctl flags the endpoint and schedules remediation. Endpoints without falconctl exit 0 and are treated as out of scope.

2. Remediation phase: The remediation script calls service falcon-sensor status first. When the service is already active, it exits 0 with no changes. When the service is stopped, the script runs service falcon-sensor start and falls back to systemctl start falcon-sensor on hosts where the older SysV wrapper is missing. The script then sleeps three seconds for the daemon to register, runs service falcon-sensor status again, and exits 0 on a successful start. A second failed status check exits 1 with a message to the Automox activity log, so the failure surfaces in the policy report instead of going silent.

Falcon sensor verification requirements

• Linux endpoint running a CrowdStrike-supported distribution (RHEL, CentOS, Rocky, Alma, Ubuntu, Debian) with the falcon-sensor package pre-installed at /opt/CrowdStrike/

• Root or sudo privileges for the Automox agent, which are required to invoke falconctl and to start or stop falcon-sensor

• Outbound network reachability from the endpoint to the CrowdStrike cloud (ts01-b.cloudsink.net or the region-specific Falcon backend) so the agent ID query succeeds

• falcon-sensor managed by service or systemctl; the Worklet calls service first and falls back to systemctl start falcon-sensor on pure systemd hosts

• Compatible with FixNow for one-click triage when a SOC alert reports a missing Falcon heartbeat on a specific host

Expected Falcon state after the Worklet runs

After a successful remediation, /opt/CrowdStrike/falconctl -g --aid returns the agent ID without an error, and service falcon-sensor status or systemctl status falcon-sensor reports active (running). The endpoint resumes posting telemetry to the Falcon console, and the host reappears as online with a fresh last-seen timestamp in the CrowdStrike Hosts view. Subsequent Worklet runs find the sensor already active and exit without applying remediation, which keeps the policy log clean and the change history accurate.

When a remediation exits non-zero, the activity report contains the CrowdStrike Falcon could not start or connect to CrowdStrike message from the script. Investigate the host directly. Check journalctl -u falcon-sensor for daemon errors, confirm the installed sensor version against the running kernel with /opt/CrowdStrike/falconctl -g --version and uname -r, and verify the host can reach the regional Falcon endpoint. The Worklet stays scheduled, so once the underlying issue is fixed the next evaluation closes the finding automatically.