Skip to main content

Troubleshooting: Monarx Auditd Plugin Not Detecting or Reporting File Events

Written by Salvador Aguilar

Overview

If Monarx isn't showing real-time file activity, or you suspect the auditd integration isn't reporting events correctly, this article walks through diagnosing and fixing the most common causes — from the audit subsystem itself not running, to the monarx-agent-auditd package missing, to rules not being loaded. It assumes you've already followed Auditd Overview and Installation to install the plugin.

This guide covers two distribution families, since package managers, repo setup, and a couple of diagnostic checks differ between them:

  • RPM-based: CentOS, RHEL, CloudLinux, AlmaLinux, Rocky Linux

  • Debian-based: Ubuntu, Debian

Steps that are identical across both families are marked (all distros). Steps that differ have a tab for each family — run the commands under your distro's heading.

Symptoms

  • Monarx dashboard shows delayed or missing detections for file-based malware that should trigger near-real-time alerts

  • auditctl -l | grep monarx returns nothing

  • systemctl status auditd shows the service inactive, failed, or missing the Monarx auditd process

  • No new lines appear in /var/log/audit/audit.log when a monitored file is created or modified

  • The monarx-agent-auditd package is missing or fails to install

Cause

The Monarx auditd integration depends on three things all working together: the Linux auditd service running with the audit subsystem enabled at the kernel level, the monarx-agent-auditd package installed and having loaded its watch rules (monarx_audit, monarx_filemon), and those events being read and forwarded correctly. A break at any layer — service down, rules not loaded, package missing, or the repo/package mismatched to your distro — will look like "Monarx isn't detecting anything," even though the agent itself is otherwise healthy.

Solution

Work through these in order — each step assumes the previous one passed.

Step 1: Confirm auditd itself is running (all distros)

systemctl status auditd
systemctl is-enabled auditd

Also check the kernel-level audit status, since auditd can show as "active" while the audit subsystem is disabled or degraded:

auditctl -s

Confirm enabled is 1 (or 2 if rules are locked immutable) and that lost is 0. A nonzero lost count means the kernel is dropping audit events, typically due to buffer size (-b) or rate limits (-r) being too low for the server's activity level — increase these in /etc/audit/auditd.conf or your rules file if so.

If auditd is not running, start it and check the logs for why it failed:

sudo systemctl start auditd 
journalctl -u auditd -n 50 --no-pager

Note (RPM-based only): on CentOS/RHEL/CloudLinux/Alma/Rocky, auditd is normally preinstalled as part of the base OS. If it's missing entirely, install it with sudo yum install audit audit-libs before continuing.

Note (Debian-based only): on Ubuntu/Debian, auditd is not installed by default. If it's missing, install it with sudo apt install auditd audispd-plugins before continuing.

Step 2: Confirm the monarx-agent-auditd package is installed

CentOS / RHEL / CloudLinux / AlmaLinux / Rocky Linux:

rpm -q monarx-agent-auditd

If it's missing, reinstall it:

curl -fsS https://repository.monarx.com/repository/monarx-yum/monarx.repo | sudo tee /etc/yum.repos.d/monarx.repo 
sudo rpm --import https://repository.monarx.com/repository/monarx/publickey/monarxpub.gpg 
sudo yum install monarx-agent-auditd

Ubuntu:

dpkg -l | grep monarx-agent-auditd

If it's missing, reinstall it:

curl -fsS https://repository.monarx.com/repository/monarx/publickey/monarxpub.gpg | sudo tee /etc/apt/trusted.gpg.d/monarx.asc 
echo "deb [arch=amd64] https://repository.monarx.com/repository/ubuntu-$(lsb_release -sc)/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/monarx.list 
sudo apt update 
sudo apt install monarx-agent-auditd

Debian:

dpkg -l | grep monarx-agent-auditd

If it's missing, reinstall it:

sudo apt-key adv --keyserver "keyserver.ubuntu.com" --recv-keys "4E240071023138C8" 
echo "deb [arch=amd64] https://repository.monarx.com/repository/debian-$(lsb_release -sc)/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/monarx.list 
sudo apt update 
sudo apt install monarx-agent-auditd

Note: Make sure you're using the block that matches your actual distro — a CentOS-family box pointed at the Ubuntu/Debian repo (or vice versa) will fail the install silently or pull an incompatible package. If unsure of your distro/codename, check with cat /etc/os-release (RPM-based) or lsb_release -a (Debian-based).

Step 3: Confirm the Monarx audit rules are loaded (all distros)

systemctl status auditd

You should see /sbin/auditd, /sbin/audispd, and /usr/bin/monarx-agent-auditd all present among the running processes.

auditctl -l | grep monarx

You should see rules tagged with the keys monarx_audit and monarx_filemon. If this returns nothing:

  • Restart the auditd plugin process so it re-registers its rules:

  sudo systemctl restart monarx-agent-auditd 2>/dev/null || sudo systemctl restart auditd

  • Check that the rules weren't wiped by a conflicting audit rules file. If you or another tool (e.g., a CIS hardening script) manages /etc/audit/rules.d/*.rules and runs augenrules --load after Monarx's rules were applied, it can overwrite them. Confirm with:

  augenrules --check

  • If rules are set immutable (-e 2), any change — including re-adding Monarx's rules — requires a reboot to take effect.

This step and its commands are identical on both distro families; only the location package managers put auditd's default rule files can differ (/etc/audit/rules.d/audit.rules on both, but Debian-based systems may also ship /etc/audit/rules.d/*.rules fragments from audispd-plugins).

Step 4: Generate a test event and confirm it's captured end-to-end (all distros)

Create a test file and confirm it shows up in the audit log:

touch /etc/test-monarx-audit 
ausearch -f /etc/test-monarx-audit 
tail -20 /var/log/audit/audit.log

If the event appears in ausearch/audit.log but never shows up in the Monarx dashboard, the audit subsystem itself is healthy and the issue is in how monarx-agent-auditd is consuming or forwarding those events — proceed to Step 5. If the event doesn't appear at all, the problem is upstream (kernel audit subsystem or auditd itself) — revisit Steps 1–3.

Step 5: Check the Monarx agent and auditd plugin logs (all distros)

sudo systemctl status monarx-agent-auditd 
journalctl -u monarx-agent-auditd -n 100 --no-pager

Look for connection errors, permission errors, or repeated restarts. Also confirm the base Monarx agent itself is healthy, since the auditd plugin reports through it — a disconnected or outdated core agent will make auditd events look "missing" even when they're being captured correctly. See Troubleshooting Monarx Agent Update Issues for that layer.

Step 6: Rule out resource or permission issues

Confirm the server isn't out of disk space in /var/log on either family — a full disk can silently stop audit logging:

df -h /var/log

CentOS / RHEL / CloudLinux / AlmaLinux / Rocky Linux: these distros ship with SELinux, which can block the plugin. Check for denials:

sudo ausearch -m avc -ts recent

If you see AVC denials referencing monarx or auditd, work with your team (or Monarx support) on an appropriate policy exception rather than disabling SELinux outright.

Ubuntu / Debian: these distros typically use AppArmor instead of SELinux. Check for denials in the kernel log:

sudo dmesg | grep -i apparmor | grep -i monarx 
sudo journalctl -k | grep -i apparmor | grep -i denied

Prevention

  • Don't run other tools that manage /etc/audit/rules.d/*.rules (CIS scripts, other security agents) without accounting for Monarx's monarx_audit / monarx_filemon rules — reapply or merge them after any rules regeneration, on either distro family.

  • Monitor auditctl -s periodically (or via your monitoring stack) for a nonzero lost count, which indicates the buffer is undersized for the server's file activity.

  • Keep monarx-agent-auditd on the same update cadence as the core Monarx agent so plugin and agent versions stay compatible — via yum update / dnf update on RPM-based systems, or apt update && apt upgrade on Debian-based systems.

  • On Ubuntu/Debian, remember auditd isn't installed by default the way it is on the RHEL family — confirm it's present after any base-image rebuild.

Still Having Issues?

If you've worked through all six steps and file events still aren't appearing in the Monarx dashboard, contact Monarx support with your distro/version (cat /etc/os-release) and the output of:

auditctl -s 
auditctl -l | grep monarx 
systemctl status auditd monarx-agent-auditd 
journalctl -u monarx-agent-auditd -n 100 --no-pager

Related Articles

Related Articles
Did this answer your question?