I have two servers with a common issue. Some, not all sites are not start php-fpm automatically after a php-fpm restart or after a server restart.
Restarting the pool isn’t sufficient, I have to click the Change Version button without changing the version and then restart the pool.
Any suggestions? Nothing remarkable in the logs.
It doesn’t seem to be all accounts, just some and it’s typically always the same accounts.
[root@p103 ~]# cat /home/virtual/site175/info/php-policy.yml
global:
version: '8.4'
workers: 18
governor: ondemand
idle_timeout: 60s
threads: 3
backlog: 30
connect: 5s
resources: { file_size: 4G, oom_adjust: 500 }
php_settings: { memory_limit: 384M }
privatetmp: null
log: { level: error, slow_threshold: 0, slow_log: null }
pools: null
blacklist: null
whitelist: null
[root@p103 ~]# cat /home/virtual/site175/info/current/apache
[DEFAULT]
version=3.2
enabled=1
webserver=www.domain.com
subnum=None
jail=1
webuser=apache
[root@p103 ~]# cat /home/virtual/site175/info/current/php
[DEFAULT]
version=3.2
enabled=1
user=apache
maxpools=1
PHP-FPM uses socket activation to launch, which is a deliberate solution to prevent a thundering herd problem on boot- otherwise you’d have 1000+ PHP-FPM daemons loading on boot resulting in a local DoS.
If a pool fails to start once data is received, see Pool fails to start.
NB: php-fpm-siteXX was renamed to php-fpm@siteXX for the upcoming release.
Ok, that nailed it for 2 sites on 1 server
This looks like an artifact of migrating from a server with PHP 8.0 to one without, the site is currently on 8.4 and no matter what version I change it to, it still has this one failure on socket activation. Is there a fix for this or do I need to modify the files manually?
Jul 13 19:14:03 p103.lithium.hosting systemd[1180127]: php-fpm-site175-domain.com.service: Failed to execute command: No such file or directory
Jul 13 19:14:03 p103.lithium.hosting systemd[1180127]: php-fpm-site175-domain.com.service: Failed at step EXEC spawning /.socket/php/multiphp/native/8.0/sbin/php-fpm: No such file or directory
On the other server, I have one site that constantly gives me issues. The same thing fixes it every time. Click change PHP version in ApisCP and then restart the PHP pool. Comes up and works fine until the next reboot or php-fpm restart.
[root@p102 ~]# journalctl -n20 -u php-fpm-site172-domain.com.service
-- Logs begin at Mon 2026-07-13 03:27:40 UTC, end at Tue 2026-07-14 13:48:21 UTC. --
Jul 13 18:20:57 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Failed with result 'exit-code'.
Jul 13 18:20:57 p102.lithium.hosting systemd[1]: Failed to start PHP worker for site172 - domain.com.
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Service RestartSec=750ms expired, scheduling restart.
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Scheduled restart job, restart counter is at 2.
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: Stopped PHP worker for site172 - domain.com.
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: Starting PHP worker for site172 - domain.com...
Jul 13 18:20:58 p102.lithium.hosting php-fpm/site172-domain.com[1107555]: [13-Jul-2026 18:20:58] WARNING: Nothing matches the include pattern '/etc/php-fpm.d/*.conf' from /etc/php-fpm.d/sites/filmmusicn>
Jul 13 18:20:58 p102.lithium.hosting php-fpm/site172-domain.com[1107555]: [13-Jul-2026 18:20:58] ERROR: failed to open error_log (/var/log/php-fpm/domain.com.log): Permission denied (13)
Jul 13 18:20:58 p102.lithium.hosting php-fpm/site172-domain.com[1107555]: [13-Jul-2026 18:20:58] ERROR: failed to post process the configuration
Jul 13 18:20:58 p102.lithium.hosting php-fpm/site172-domain.com[1107555]: [13-Jul-2026 18:20:58] ERROR: FPM initialization failed
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: New main PID 1107549 does not belong to service, and PID file is not owned by root. Refusing.
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Main process exited, code=exited, status=78/CONFIG
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Failed with result 'exit-code'.
Jul 13 18:20:58 p102.lithium.hosting systemd[1]: Failed to start PHP worker for site172 - domain.com.
Jul 13 18:20:59 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Service RestartSec=750ms expired, scheduling restart.
Jul 13 18:20:59 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Scheduled restart job, restart counter is at 3.
Jul 13 18:20:59 p102.lithium.hosting systemd[1]: Stopped PHP worker for site172 - domain.com.
Jul 13 18:20:59 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Start request repeated too quickly.
Jul 13 18:20:59 p102.lithium.hosting systemd[1]: php-fpm-site172-domain.com.service: Failed with result 'exit-code'.
Jul 13 18:20:59 p102.lithium.hosting systemd[1]: Failed to start PHP worker for site172 - domain.com.
Migration script will generate a warning. Whether one acts upon the warning or not is up to them. Migrations are always 1:1 preservation because if a migration deviates, then it inspires people to find flaws where flaws don’t exist as they can’t trust a 1:1 migration to make a true 1:1 copy.
Site is at quota on xfs (quota -gva adminXX). This is how an xfs filesystem works. ext4 will report EDQUOTA, a different code that’s a bit more useful in this scenario.
Ok, I don’t read the migration log for all sites during a full server migration. If it fails I fix it but if it succeeds and works after, not sure why I’d look at the log.
That said, what’s the process to force the site to use the version selected if the version selector doesn’t do that?
Version selector does when effected by PHP > PHP Pools. When migrating a site, if the target server lacks the requested PHP version, it still defaults to that PHP version out of an abundance of caution and to preserve the 1:1 expectation.
You can add PHP 8.0 on the new server to solve this concern. cpcmd scope:set php.multi 8.0
Let’s assume that I don’t want PHP 8.0 but the migration has already happened.
The issue I’m trying to solve is that service/socket having a PHP 8.0 definition while the PHP selector in ApisCP shows 8.4. Clicking Change Version and restarting the pool works, but it doesn’t update the underlying service/socket files. Do I need to do that manually or is there a way to reconcile things properly?
Just had another report of 503 error, same server and not a quota issue.
Like I said, if I change the PHP Version (same version works) and restart the pool it fires right up.
lgtm. Cannot reproduce with the information as provided. See attached screengrab. Editing a domain performs a pool version check. Changing the pool version within the UI performs the corresponding EditDomain function. Note warning up top upon changing pool version through “Change Version”.
# cpcmd -d site4 php:pool-get-version
8.0
# cpcmd -d site4 php:pool-get-version
8.2
I don’t know then. From my experience, it’s quota. Bear in mind, if the PHP pool is ran by a user other than “apache” or the account user, that’s an additional quota (quota -uv #UID). If the user was at quota before, and logrotation could not complete, then the new PHP-FPM log, /var/log/php-fpm/POOL-NAME.log, will not be created with proper permissions. EditDomain --reconfig siteXX will create the necessary logfile, however.
Here’s an example I’m basing my advice on:
Jul 15 08:47:58 orion systemd: Starting PHP worker for site75 - x.com...
Jul 15 08:48:05 orion php-fpm/site75-x.com: [15-Jul-2026 08:48:05] ERROR: failed to open error_log (/var/log/php-fpm/x.com.log): Permission denied (13)
Jul 15 08:48:05 orion php-fpm/site75-x.com: [15-Jul-2026 08:48:05] ERROR: failed to post process the configuration
Jul 15 08:48:05 orion php-fpm/site75-x.com: [15-Jul-2026 08:48:05] ERROR: FPM initialization failed
Jul 15 08:48:05 orion systemd: php-fpm@site75-x.com.service: main process exited, code=exited, status=78/n/a
# quota -gv admin75
Disk quotas for group admin75 (gid 1099):
Filesystem blocks quota limit grace files quota limit grace
/dev/vda1 1792000* 1790976 1792000 none 8540 0 0
# systemctl show -pUser php-fpm@site75-x.com.service
User=48@site75
The following command fails because user apache does not have unconditional write-access to files in this directory, c.f. symlink attack resolved in #a7d53725.
# runuser -u 48@site75 -g admin75 touch /var/log/php-fpm/x.log
touch: cannot touch ‘/var/log/php-fpm/x.log’: Permission denied
# cpcmd -d site75 site:storage-amnesty
# quota -gv admin75
Disk quotas for group admin75 (gid 1099):
Filesystem blocks quota limit grace files quota limit grace
/dev/vda1 1792004 3582976 3584000 8540 0 0
# EditDomain --reconfig site75
# runuser -u 48@site75 -g admin75 touch /var/log/php-fpm/x.log
Command succeeds because /var/log/php-fpm/x.log exists. These files are created every time existing logs rotate as carried out by /etc/cron.daily/logrotate within the site vfs.
Ok, this is where I’m at:
[root@p103 ~]# cpcmd -d site175 php:pool-get-version
8.4
/etc/systemd/system/php-fpm-site175-domain.com.service
[Service]
User=48@site175
Group=1207
PIDFile=/home/virtual/site175/fst/var/run/php-fpm/domain.com.pid
Environment="FPM_SOCKETS=/var/run/php-fpm/site175-domain.com.socket=3"
ExecStart=/.socket/php/multiphp/native/8.0/sbin/php-fpm --nodaemonize --fpm-config=/etc/php-fpm.d/sites/domain.com.conf
ExecStartPost=+/usr/sbin/chroot /home/virtual/site175/fst /bin/cgclassify $MAINPID
ExecReload=/bin/kill -USR2 $MAINPID
Changing the Version in ApisCP does not update the /etc/systemd/system/php-fpm-site175-domain.com.service file with the new ExecStart value. To be sure, I changed to 8.3, the change worked and the site failed to load due to composer PHP version requirements. I checked the pool version via the command which confirmed 8.3 but the service file still says 8.0.
It’s php-fpm@site175-domain.com.service for all edge releases. php-fpm-siteXX is no longer used because it’s non-instantiatable.
upcp -m '*service-master-classes*'