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:
How does Virtualmin handle the restart internally? Does it use a wrapper that ensures certain paths or permissions exist before launching the service?
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?
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?
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.
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?
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: