• Hosting Flash Sale: Starting at $0.43/mo for a limited time
Client Area
Client Area

Fixing “No pool defined” and PHP-FPM Service Failures After a cPanel / CloudLinux Update

Fixing “No pool defined” and PHP-FPM Service Failures After a cPanel / CloudLinux Update

A routine cPanel/WHM or CloudLinux maintenance update can occasionally trigger alerts from chkservd or fail the restart runner with output like:
[ERROR] Failed to perform action “restart” for php-fpm “alt-83”: 
The “/usr/bin/systemctl restart alt-php83-fpm” command reported error number 1.
Cpanel::Exception::Services::RestartError
Checking journalctl -xe or systemctl status usually highlights the direct cause:
WARNING: Nothing matches the include pattern '/opt/alt/php83/etc/php-fpm.d/*.conf'
ERROR: No pool defined. at least one pool section must be specified in config file
ERROR: FPM initialization failed
systemd[1]: alt-php83-fpm.service: Main process exited, code=exited, status=78/CONFIG
Here is an analysis of why this happens after maintenance runs and how to resolve it quickly.

Root Cause

The master configuration file for PHP-FPM (/opt/alt/phpXX/etc/php-fpm.conf) requires at least one active worker pool defined to start. It reads domain pools dynamically via an include directive:
Ini, TOML

include=/opt/alt/phpXX/etc/php-fpm.d/*.conf
During updates, cPanel’s service manager evaluates all installed PHP versions. If CloudLinux alt-php packages (such as alt-php80, alt-php81, or alt-php83) are installed on the server but have no domains actively assigned to them, their /etc/php-fpm.d/ directories remain empty.
When cPanel tries to bring up or restart apache_php_fpm, systemd attempts to launch the respective alt-phpXX-fpm services. PHP-FPM finds zero pools, exits with status 78/CONFIG, and causes cPanel’s service runner to abort.

The Solution

Step 1: Attempt cPanel’s Native Rebuild

Before making manual changes, verify whether any accounts should have active pools generated:
Bash

/usr/local/cpanel/scripts/php_fpm_config --rebuild
If domains are assigned to these versions, this command regenerates the missing configuration blocks.

Step 2: Create a Lightweight Fallback Pool

If the versions are installed but currently unassigned to any domain, configure a lightweight, zero-overhead dummy pool. This satisfies PHP-FPM’s configuration parser without tying up memory or running active workers.
Run the following loop in your root shell:
Bash

for ver in 80 81 83; do
  mkdir -p /opt/alt/php${ver}/etc/php-fpm.d/
  cat << EOF > /opt/alt/php${ver}/etc/php-fpm.d/default.conf
[default]
user = nobody
group = nobody
listen = 127.0.0.1:190${ver}
pm = ondemand
pm.max_children = 2
pm.process_idle_timeout = 60s
EOF
  systemctl restart alt-php${ver}-fpm
done
Note: Replace 80 81 83 with whichever alt-php or ea-php versions triggered the alert on your server.

Step 3: Restart the cPanel PHP-FPM Wrapper

Once the individual systemd units are active, restart the main service runner:
Bash

/scripts/restartsrv_apache_php_fpm --start
You should see each daemon initialize cleanly:
Plaintext

Service Status
        Found 5 versions of PHP-FPM: 83 82 alt-83 alt-81 alt-80

apache_php_fpm restarted successfully.

Behavior on LiteSpeed Web Server (LSWS)

If your stack runs LiteSpeed Web Server, website traffic generally processes through LiteSpeed’s native LSPHP binaries (lsphp) rather than standard systemd PHP-FPM daemons.
However, cPanel’s watchdog (chkservd) continues monitoring the systemd apache_php_fpm service targets in the background. Adding lightweight fallback pools prevents false-positive alerts, clears chkservd failure tickets, and keeps the server health dashboard completely green.
Tags: