Issue restarting additional PHP-FPM (Remi) versions via systemctl

Hi everyone,

I’m running Virtualmin on AlmaLinux 9, and I have multiple PHP versions installed via Remi (7.4, 8.1, 8.2, 8.3, and 8.4), all using phpXY-php-fpm services alongside the default php-fpm.service (which corresponds to PHP 8.0 installed via system packages).

Everything works fine when the FPM services are started or restarted via the Virtualmin web interface — the socket files (e.g. /run/php-fpm/17520656849369.sock) are created correctly, and the websites using those PHP versions respond normally.

However, if I try to restart the same services via systemctl restart php84-php-fpm (or any other version), the .sock file is not created, and FPM doesn’t listen on the expected socket path, breaking the website with a “503 Service Unavailable” error.

I’ve verified that:

  • The socket is correctly defined in /etc/opt/remi/php84/php-fpm.d/xxxxx.conf
  • SELinux is disabled (getenforce returns Disabled)
  • The parent folder /run/php-fpm/ exists but is owned by root:root (as expected)
  • No errors are logged unless I explicitly stop and restart via systemctl — and even then, systemctl thinks it started correctly
  • Using sudo -u to write to /run/php-fpm/ fails, as expected, due to permissions

The odd part is that restarting from the Web UI always works, while systemctl restart does not.

My questions:

  1. How does Virtualmin handle the restart internally? Does it use a wrapper that ensures certain paths or permissions exist before launching the service?
  2. Is there a recommended way to restart all phpXY-php-fpm services from the CLI in the same way Webmin does, to ensure everything is initialized properly?
  3. Regarding PHP 8.0 (the system default): would you recommend keeping it installed as-is, or would it be better to remove it and install PHP 8.0 from the Remi repository too, for consistency with the other versions?

Thanks in advance for your help!

SYSTEM INFORMATION
OS type and version AlmaLinux release 9.6
Virtualmin version 7.30.8

What error is produce when you do a restart, works fine on my Rocky 9 server

Thanks for your reply!

I can confirm that the services restart correctly on my system too — no visible error from systemctl restart phpXX-php-fpm.

However, the problem is that after the restart, the socket file (e.g. /run/php-fpm/xxxxx.sock) disappears and doesn’t get recreated. As a result, any virtual server using that PHP version through FPM immediately starts returning 503 Service Unavailable errors due to the missing socket.

If I restart the same PHP-FPM service from Virtualmin’s UI, everything works perfectly: the socket is recreated and the sites respond correctly.

So the issue isn’t with the service failing to start, but rather with the socket not being created unless the restart is done through Virtualmin.

Thanks again for your help!

That is weird, only thing I can think if its just one virtual server is to disable and enable it.

I rebooted the server and the issue hasn’t occurred again so far. I’ll keep investigating to see if I can find any connection with the previous problem. Thanks again for your help!

By the way, regarding PHP 8.0 — would you recommend replacing the default system version with the one from Remi, or is it better to keep the default one installed alongside the others from Remi?

No I would leave the default system version.

Thanks! I understand — I’ll leave the default system version of PHP 8.0 as-is.

By the way, I’ve figured out what was causing the issue.

Everything works fine when I create a virtual server via the graphical interface. However, when I create a domain from the CLI using the following command:
virtualmin create-domain
–domain test9.domain.com
–pass ‘Test123Secure!’
–desc “test9”
–web --ssl --mysql --logrotate
–unix --dir

The domain is created successfully, but the associated PHP-FPM socket (e.g., in /run/php-fpm/) is not created, resulting in a 503 Service Unavailable error when accessing the site.

Even more oddly, running this command seems to remove previously existing PHP-FPM sockets created for other virtual servers. Here’s an example right after domain creation:

[root@testcp ~]# ls -lia /run/php-fpm/
total 4
1652 drwxr-xr-x 2 root root 120 10 Jul 09:46 .
1 drwxr-xr-x 40 root root 1120 10 Jul 09:46 ..
1655 srw-rw---- 1 _default_hostname _default_hostname 0 10 Jul 09:46 175190710320300.sock
1656 srw-rw---- 1 test9 test9 0 10 Jul 09:46 17521335594343.sock
1658 -rw-r–r-- 1 root root 4 10 Jul 09:46 php-fpm.pid
1657 srw-rw----+ 1 root root 0 10 Jul 09:46 www.sock

All the other previously active .sock files disappeared right after running the virtualmin create-domain command.

I’m continuing to investigate, but this looks like an unintended side effect that could impact multiple sites relying on PHP-FPM.

Hope this helps clarify the behavior.

Right, maybe one of the staff might know what causing that.