CloudPanel version(s) affected
2.5.4-3+clp-noble (Ubuntu 24.04 / Noble)
Description
When changing the PHP version for a site via the CloudPanel UI, the new PHP-FPM pool config generated for that site can reuse a TCP port that is already assigned to another site's pool for the same PHP version. Since PHP-FPM validates all pools on startup and refuses to start if any listen address collides, the entire PHP-FPM instance for that version fails to start — not just the one affected pool. This takes down every other site running on that same PHP version, and there is nothing about it in the CloudPanel UI logs.
This is not isolated to a single site — it has been observed across multiple sites and multiple PHP versions on the same server (documented below for two cases involving PHP 8.3 and PHP 8.5), which points to a general flaw in the port-assignment logic rather than a one-off/site-specific data issue.
How to reproduce
Have multiple sites on a CloudPanel instance, each with a dedicated PHP-FPM pool (i.e. more than just the default.conf pool) for a given PHP version.
In the CloudPanel UI, go to Sites → (any site) → PHP Settings.
Change the PHP version (e.g. to 8.3, or separately to 8.5).
Observe that the affected PHP-FPM service (e.g. php8.3-fpm / php8.5-fpm) fails to start, because the newly written pool config reuses a port already assigned to another site's pool.
Case 1 — PHP 8.3
Pool files before fix:
/etc/php/8.3/fpm/pool.d/default.conf:listen = 127.0.0.1:18000
/etc/php/8.3/fpm/pool.d/site-c.example.conf:listen = 127.0.0.1:18001
/etc/php/8.3/fpm/pool.d/site-a.example.conf:listen = 127.0.0.1:18001 <-- collision
/etc/php/8.3/fpm/pool.d/site-b.example.conf:listen = 127.0.0.1:18001 <-- collision
systemctl status php8.3-fpm:
Main PID: 3582098 (code=exited, status=78)
journalctl -xeu php8.3-fpm.service:
ERROR: [pool site-a.example] unable to set listen address as it's already used in another pool 'site-c.example'
ERROR: failed to post process the configuration
ERROR: FPM initialization failed
Fixed manually by editing the pool files to use unique ports (18002, 18003) and restarting the service.
Case 2 — PHP 8.5 (same site, different PHP version, days later)
After switching site-a.example to PHP 8.5 via the UI, the same collision pattern reappeared, this time against a different site:
/etc/php/8.5/fpm/pool.d/default.conf:listen = 127.0.0.1:20000
/etc/php/8.5/fpm/pool.d/site-a.example.conf:listen = 127.0.0.1:20001 <-- collision
/etc/php/8.5/fpm/pool.d/site-d.example.conf:listen = 127.0.0.1:20001 <-- collision
systemctl status php8.5-fpm:
Main PID: 3594584 (code=exited, status=78)
Same error signature as Case 1. Fixed manually the same way (unique port 20002).
Possible Solution
CloudPanel should assign a unique listen port to the new pool file, checking against all existing listen = entries in /etc/php//fpm/pool.d/*.conf for that PHP version, so that PHP-FPM starts successfully with no manual intervention.
Additional Context
The collisions observed so far both involved site-a.example on the triggering side, but colliding against two different other sites (site-c.example on PHP 8.3, site-d.example on PHP 8.5) — i.e. the receiving end of the collision changes each time, which points to the assignment logic simply not scanning existing ports correctly at the moment a new/changed pool file is written, rather than any one site's stored data being corrupt.
Both times the failure occurred during/after an unrelated apt package update was running, so it's possible (but unconfirmed) that the port assignment logic reads/writes some cached state that gets out of sync during a CloudPanel package update. Flagging this as a possible contributing factor, not a confirmed root cause.
No error surfaced in the CloudPanel UI or its own logs — this was only diagnosed via systemctl status, journalctl, and php-fpm -t at the shell.
After manually fixing the port, nginx continued serving the site correctly without needing changes on the nginx side (nginx picked up the corrected port after the pool restart).
CloudPanel version(s) affected
2.5.4-3+clp-noble (Ubuntu 24.04 / Noble)
Description
When changing the PHP version for a site via the CloudPanel UI, the new PHP-FPM pool config generated for that site can reuse a TCP port that is already assigned to another site's pool for the same PHP version. Since PHP-FPM validates all pools on startup and refuses to start if any listen address collides, the entire PHP-FPM instance for that version fails to start — not just the one affected pool. This takes down every other site running on that same PHP version, and there is nothing about it in the CloudPanel UI logs.
This is not isolated to a single site — it has been observed across multiple sites and multiple PHP versions on the same server (documented below for two cases involving PHP 8.3 and PHP 8.5), which points to a general flaw in the port-assignment logic rather than a one-off/site-specific data issue.
How to reproduce
Have multiple sites on a CloudPanel instance, each with a dedicated PHP-FPM pool (i.e. more than just the default.conf pool) for a given PHP version.
In the CloudPanel UI, go to Sites → (any site) → PHP Settings.
Change the PHP version (e.g. to 8.3, or separately to 8.5).
Observe that the affected PHP-FPM service (e.g. php8.3-fpm / php8.5-fpm) fails to start, because the newly written pool config reuses a port already assigned to another site's pool.
Case 1 — PHP 8.3
Pool files before fix:
/etc/php/8.3/fpm/pool.d/default.conf:listen = 127.0.0.1:18000
/etc/php/8.3/fpm/pool.d/site-c.example.conf:listen = 127.0.0.1:18001
/etc/php/8.3/fpm/pool.d/site-a.example.conf:listen = 127.0.0.1:18001 <-- collision
/etc/php/8.3/fpm/pool.d/site-b.example.conf:listen = 127.0.0.1:18001 <-- collision
systemctl status php8.3-fpm:
Main PID: 3582098 (code=exited, status=78)
journalctl -xeu php8.3-fpm.service:
ERROR: [pool site-a.example] unable to set listen address as it's already used in another pool 'site-c.example'
ERROR: failed to post process the configuration
ERROR: FPM initialization failed
Fixed manually by editing the pool files to use unique ports (18002, 18003) and restarting the service.
Case 2 — PHP 8.5 (same site, different PHP version, days later)
After switching site-a.example to PHP 8.5 via the UI, the same collision pattern reappeared, this time against a different site:
/etc/php/8.5/fpm/pool.d/default.conf:listen = 127.0.0.1:20000
/etc/php/8.5/fpm/pool.d/site-a.example.conf:listen = 127.0.0.1:20001 <-- collision
/etc/php/8.5/fpm/pool.d/site-d.example.conf:listen = 127.0.0.1:20001 <-- collision
systemctl status php8.5-fpm:
Main PID: 3594584 (code=exited, status=78)
Same error signature as Case 1. Fixed manually the same way (unique port 20002).
Possible Solution
CloudPanel should assign a unique listen port to the new pool file, checking against all existing listen = entries in /etc/php//fpm/pool.d/*.conf for that PHP version, so that PHP-FPM starts successfully with no manual intervention.
Additional Context
The collisions observed so far both involved site-a.example on the triggering side, but colliding against two different other sites (site-c.example on PHP 8.3, site-d.example on PHP 8.5) — i.e. the receiving end of the collision changes each time, which points to the assignment logic simply not scanning existing ports correctly at the moment a new/changed pool file is written, rather than any one site's stored data being corrupt.
Both times the failure occurred during/after an unrelated apt package update was running, so it's possible (but unconfirmed) that the port assignment logic reads/writes some cached state that gets out of sync during a CloudPanel package update. Flagging this as a possible contributing factor, not a confirmed root cause.
No error surfaced in the CloudPanel UI or its own logs — this was only diagnosed via systemctl status, journalctl, and php-fpm -t at the shell.
After manually fixing the port, nginx continued serving the site correctly without needing changes on the nginx side (nginx picked up the corrected port after the pool restart).