PHP-FPM fails to start on newly provisioned ApisCP. Deploying a new ApisCP install on a fresh Linode with Almalinux 9 image runs into a problem with PHP-FPM not able to start and no reporting.
Steps to Reproduce
Provision a new Linode with Almalinux 9 image.
Update. Then run ApisCP bootstrap. (Options PHP 8.4, MariaDB 11.8, and PostgreSQL 16)
After install, upcp -sb, yum update, and reboot to double check.
Expected Behavior
Websites created or transfer work without a hitch.
Actual Behavior
Websites with PHP are showing a 503 Service Unavailable. This is from PHP-FPM not being available. Websites without PHP are 403 Forbidden. This affects sites created from scratch. Nexus → Web → PHP Pools list as “Inactive (socket activation)” Trying to restart will pop up a message that says it failed: “Php_Module::pool_set_state(): Failed to restart site1-domain.com” Pressing start will actually list as “Action succeeded”. Also of note, PHP-FPM cannot be toggled off from ApisCP configuration setting.
journalctl -n20 -u php-fpm-siteXX-NAME.service shows no entries.
This is normal. PHP-FPM activates when data comes across the wire from Apache.
This has been renamed to php-fpm@siteXX-NAME as of 3.2.49.
Looks fine to me on EL10. Here’s a test:
root@testing:~# AddDomain -c siteinfo,domain=foo.com
INFO : no billing identifier specified for site, generated `apnscp-PAAKCBUY'
INFO : no mysql database prefix specified - suggesting `fooc_'
INFO : no bandwidth rollover date specified, using day of month, `27'
INFO : No password specified - generating random password: `cQm7iBWrevdUDONicYndAuVvgKtVX7hZ'
INFO : allocated port range [40010,40019] for account
INFO : DNS not configured for `foo.com', bypassing DNS hooks
WARNING: Email_Module::add_virtual_transport(): DNS is not configured for `foo.com' - unable to provision DNS automatically
root@testing:~# echo '<?php echo "Hello world!";' > /home/virtual/foo.com/var/www/html/index.php
root@testing:~# ls -la /home/virtual/foo.com/var/www/html/
total 24
drwxr-xr-x 2 admin1 admin1 4096 Sep 27 02:02 .
drwxr-xr-x 3 admin1 admin1 4096 Sep 27 02:01 ..
-rwxr-xr-x 1 admin1 admin1 9934 Sep 27 02:01 index.html
-rw-r--r-- 1 root root 27 Sep 27 02:02 index.php
root@testing:~# htrebuild
Reloading httpd: Syntax OK
root@testing:~# curl --resolve foo.com:80:$(cpcmd -d foo.com site:ip-address) http://foo.com/index.php
Hello world!
The original test was a Wordpress transfer site. It would produce a 503 error when live on the web. I just spun up a new Linode instance and did an install, and the default page isn’t loading with the Forbidden error on a live domain. ApisCP backend and Nexus all working like expected.
Cool. I tried it without .service as well. Same results.
Rebooted the server and was greeted with it asking to check:
systemctl status php-fpm@site3-foo.com.service
[root@forge ~]# systemctl status php-fpm@site3-foo.com.service
× php-fpm@site3-foo.com.service - PHP worker for site3 - foo.com
Loaded: loaded (/etc/systemd/system/php-fpm@site3-foo.com.service; static)
Active: failed (Result: exit-code) since Sat 2025-09-27 06:42:43 UTC; 1min 47s ago
TriggeredBy: × php-fpm@site3-foo.com.socket
Process: 3552 ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config=/etc/php-fpm.d/sites/foo.com.conf (code=exited, status=127)
Main PID: 3552 (code=exited, status=127)
CPU: 17ms
Sep 27 06:42:43 apiscp.newserver.com systemd[1]: php-fpm@site3-foo.com.service: Scheduled restart job, restart counter is at 3.
Sep 27 06:42:43 apiscp.newserver.com systemd[1]: Stopped PHP worker for site3 - foo.com.
Sep 27 06:42:43 apiscp.newserver.com systemd[1]: php-fpm@site3-foo.com.service: Start request repeated too quickly.
Sep 27 06:42:43 apiscp.newserver.com systemd[1]: php-fpm@site3-foo.com.service: Failed with result 'exit-code'.
Sep 27 06:42:43 apiscp.newserver.com systemd[1]: Failed to start PHP worker for site3 - foo.com.
One another note, I found the issue with the non-PHP html placeholder. Looks like the transfer needed the Let’s Encrypt to be regenerated to work. This still does not solve the 503 from php-fpm.
EditDomain --reconfig --all may be necessary to rebuild systemd configuration for these sites. In later systemd releases bundled with EL9/10, MountAPIVFS= in conjunction with RootDirectory= mounts /run as private tmpfs.