Troubleshooting: Monarx Protect Extension Not Installed or Not Loading

If php -m | grep monarxprotect returns nothing, or the Monarx web app's Agents > Extensions page doesn't show Monarx Protect as loaded or detected, this article explains why and how to fix it.

Symptoms

Protect doesn't appear under loaded extensions in the Agents module (Agent > Extensions).
php -m | grep monarxprotect returns no output.

Cause

Monarx Protect is a PHP RASP (runtime application self-protection) extension. It has to be loaded by every PHP runtime you want protected — CLI, mod_php/Apache, and each PHP-FPM pool. The monarx-protect-autodetect package handles this automatically for common setups (standard Apache, LiteSpeed, cPanel, Plesk), but it targets common configurations. If a server has a custom or non-standard PHP setup — multiple PHP versions, non-default extension directories, custom FPM pools, containerized PHP, etc. — autodetect may not find or configure every PHP runtime, and the extension needs to be installed manually.

Before You Begin: Verify the Monarx Repository Is Reachable

Both the autodetect and manual paths below install packages from the Monarx repository. If that repository was never added, isn't enabled, or is blocked by a firewall/proxy, the install commands will fail (or silently install nothing) before Protect ever gets a chance to load. Check this first.

RHEL / CentOS / CloudLinux / Alma / Rocky (yum/dnf)

1. Confirm the repo file exists:

cat /etc/yum.repos.d/monarx.repo

If this doesn't exist, the Preparation step (adding the repo) was never completed — re-run it before installing anything.

2. Confirm the repo is registered and enabled:

yum repolist | grep -i monarx 
# or, on dnf-based systems 
dnf repolist enabled | grep -i monarx

No output means the repo file exists but isn't enabled, or baseurl/gpgkey in it is misconfigured.

3. Confirm the repo is actually reachable from this server:

curl -Is https://repository.monarx.com/repository/monarx-yum/monarx.repo | head -1

Expect HTTP/1.1 200 or HTTP/2 200. A timeout, connection refused, or DNS failure here means outbound access to repository.monarx.com (port 443) is blocked — check egress firewall rules or an outbound proxy before troubleshooting the extension further.

4. Confirm the GPG key was imported:

rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release}\t%{summary}\n' | grep -i monarx

5. Confirm packages actually resolve from the repo:

yum --disablerepo="*" --enablerepo="monarx*" list available

This should list monarx-agent, monarx-protect, and monarx-protect-autodetect. An empty list confirms the repo is registered but not serving packages (reachability or mirror issue).

Ubuntu / Debian (apt)

1. Confirm the sources file exists:

cat /etc/apt/sources.list.d/monarx.list

2. Confirm the signing key is present:

ls -l /etc/apt/trusted.gpg.d/monarx.asc   # Ubuntu apt-key list | grep -i monarx              # Debian (if using apt-key)

3. Confirm the repo is reachable from this server:

curl -Is https://repository.monarx.com/repository/ubuntu-$(lsb_release -sc)/ | head -1

Expect an HTTP/1.1 200 or HTTP/2 200 response. Anything else points to blocked egress, DNS resolution failure, or a proxy stripping the request.

4. Refresh apt and check for errors specific to Monarx:

sudo apt-get update 2>&1 | grep -i monarx

Watch for Failed to fetch or NO_PUBKEY errors, which indicate reachability or key-import problems respectively.

5. Confirm the packages resolve with a real candidate version:

apt-cache policy monarx-protect monarx-protect-autodetect

A Candidate: (none) result means apt doesn't see the packages — the repo isn't registered correctly or wasn't reachable during the last apt-get update.

⚠️ If any of the above checks fail, resolve connectivity/repo registration first — the installation steps below will not succeed (or will silently no-op) until the repository is reachable and enabled.

Solution

Option 1: Reinstall/repair via autodetect (try this first)

For standard Apache, LiteSpeed, cPanel, or Plesk environments, run:

# CentOS / RHEL / CloudLinux / Alma / Rocky 
sudo yum install monarx-protect-autodetect  

# Ubuntu / Debian 
sudo apt-get install monarx-protect-autodetect

This pulls in monarx-agent and monarx-protect and configures Protect for common PHP configurations it detects on the system. A web server / PHP-FPM restart is required afterward for the change to take effect. If Protect still isn't loaded after reinstalling and restarting, the setup is likely non-standard and needs manual installation (Option 2).

Option 2: Manual installation (custom/bespoke setups)

Use this when autodetect doesn't cover the server's PHP configuration — for example, multiple PHP versions running side by side (CloudLinux, cPanel EasyApache multi-PHP, Plesk PHP handlers), custom extension directories, or containerized PHP.

1. Install the base package (not autodetect):

# CentOS / RHEL / CloudLinux / Alma / Rocky 
sudo yum install monarx-protect  

# Ubuntu / Debian 
sudo apt-get install monarx-protect

This drops a .so file for each supported PHP version into a shared location, e.g. /usr/lib64/monarx-protect/:

monarxprotect-php53.so 
monarxprotect-php54.so 
... 
monarxprotect-php83.so 
monarxprotect-php84.so

2. Identify every PHP runtime on the server. A custom setup often runs more than one PHP version or SAPI (CLI, mod_php, and one or more PHP-FPM pools). Each one needs the extension installed and enabled separately — this is the step autodetect can miss.

3. For each PHP runtime, find its extension directory and config directory:

php --ini | grep extension_dir      # where the .so files need to go php --ini | grep additional          # where to drop an .ini to enable it

Run the equivalent command against each PHP binary in use (see the PHP vs. PHP-FPM section below — the CLI php binary is not necessarily the same PHP version or config used by your web server).

4. Copy or symlink the matching .so file into that PHP version's extension directory. Match the .so filename to the PHP version (e.g. monarxprotect-php84.so for PHP 8.4).

5. Enable the extension by adding a line to a .ini file in that PHP version's config/scan directory (e.g. /etc/php.d/ or wherever php --ini | grep additional points):

extension=monarxprotect-php84.so

6. Repeat steps 3–5 for every PHP version/runtime found in step 2.

7. Restart the correct service(s) — see PHP vs. PHP-FPM below, since this differs by setup.

PHP vs. PHP-FPM: Key Differences

This distinction matters most during manual installation, since it determines where the .so goes and what needs restarting.

	Standard PHP (mod_php / CLI / CGI)	PHP-FPM
Where extensions load from	The single `php.ini` (and its scan directory) used by that SAPI	Each PHP-FPM version/pool has its own `php.ini`/scan directory — even if the CLI `php.ini` looks fine, an FPM pool can be pointed at a different one
Multiple PHP versions	Less common outside of CLI switching	Very common — cPanel EasyApache, CloudLinux, and Plesk routinely run several PHP-FPM versions side by side, each needing its own `.so` and `.ini`
What to restart	Restart Apache/httpd (mod_php) — no separate PHP process to restart	Restart the specific PHP-FPM service for the version you changed (e.g. `systemctl restart php8.4-fpm`, or `ea-php84-php-fpm` on cPanel). Restarting Apache/Nginx alone does not reload PHP-FPM's loaded extensions
Verifying which binary matters	`php -m` generally reflects what's loaded for that SAPI	`php -m` on the CLI may not match what a given FPM pool is running. Check each FPM binary directly (e.g. `/opt/cpanel/ea-php84/root/usr/bin/php -m`) or use a `phpinfo()` page served through that pool
Finding active instances	`which php`, `php -v`	`ps aux \| grep php-fpm` or `systemctl list-units 'fpm'` to enumerate every running pool/version before checking each one

The practical takeaway: on a PHP-FPM server, checking only the default php CLI binary can look fine while the actual web-facing PHP-FPM pool is missing the extension entirely (or vice versa). Always verify — and restart — per PHP version/pool, not just once at the system level.

How to Check if Protect Is Installed

Use any of the following. On multi-PHP-version servers, run the CLI checks against each PHP/FPM binary in use, not just the default one.

CLI check:

   php -m | grep monarxprotect

For a specific PHP-FPM version, run the equivalent binary directly, e.g.:

   /opt/cpanel/ea-php84/root/usr/bin/php -m | grep monarxprotect

No output means the extension isn't loaded for that binary.

Monarx web app: Go to Agents, select the agent, then open the Extensions tab. Loaded and active PHP modules are listed there per agent — this reflects what's actually running, which is the most reliable check on servers with several PHP versions.
phpinfo() page (useful for confirming what a specific FPM pool loads): Serve a phpinfo(); script through the site/pool in question and search the output for monarxprotect.
Confirm the .ini and .so are in place for the PHP version being checked:

php --ini | grep additional   # scan directory — look for a monarxprotect .ini here    
php --ini | grep extension_dir  # look for the matching monarxprotect .so here

Prevention

After any manual install, restart the specific PHP-FPM service(s) affected — not just the web server.
On multi-PHP-version servers, re-check installation after adding a new PHP version, since neither autodetect nor a prior manual install will retroactively cover it.
Re-verify via the Agents > Extensions page after any PHP upgrade, as .so files are version-specific and won't carry over automatically.

Still Having Issues?

If Protect still doesn't show as loaded after a manual install and correct service restart, contact Monarx support with the output of php --ini, the PHP version(s) in use, and whether the setup uses mod_php, PHP-FPM, or both.

Source: Protect Overview and Installation