On a server PHP7.4 would not restart after doing a “routine” upgrade which upgraded (as far as I remember) PHP 8.1 packages.
Server has been working for at least for a year and a half, and multiple PHP versions have been installed as per the Virtualmin doc, everything was working fine until this upgrade.
After the upgrade a few sites went down (mostly Wordpress that were not using PHP-fpm 7.4 but PHP-fpm 8.1).
On the dashboard only PHP-fpm 7.4 was down and I was unable to restart it, error being:
Another FPM instance seems to already listen on /var/php-fpm ...
on 2 differents xxxxxxxxxxxxx.sock files …
I tried a lot of things, I had some weird results, for example stopping all PHP-fpm, if I try to start PHP-fpm 7.4 it’s PHP-fpm 8.1 that starts, weird but making sense because I discovered that those sock files were existing in both /var/php/7.4/fpm/pool.d and /var/php/8.1/fpm/pool.d…
I also tried to reinstall php 7.4 with --reinstall (maybe it was a bad idea…) but I finally was able to restart PHP-fpm 7.4 after deleting those duplicated sock files …
Of course I went each time through the re-check configuration.
The following PHP execution modes are available : cgi fcgid fpm
The following PHP versions are available : 7.4.33 (/bin/php-cgi7.4), 8.0.28 (/bin/php-cgi8.0), 8.1.18 (/bin/php-cgi8.1), 8.2.6 (/bin/php-cgi8.2)
The following PHP-FPM versions are available : 8.0.28 (php8.0-fpm) 8.1.18 (php8.1-fpm) 8.2.6 (php8.2-fpm)
Now I have all PHP-fpm up and running but I have another problem: I am unable to view the PHP-fpm 7.4 status on dashboard and I cannot choose it on individual virtualhosts … is there a way to have it re-appear in Virtualmin ?
PS: I had my websites in need of 7.4 back by choosing FCGID instead of FPM.
I’m running same OS and versions. I have 2 different 7’s because something required it. Overall, I really don’t have much on the server right now so can’t help too much other than to say mine seems to work OK even after some PHP updates.
But, have you tried to restart Webmin to see if the dashboard picks it up?
Hello
As I said I tried a force-reinstall, not sure if this is the same:
apt-get --reinstall install php7.4-fpm{......}
I said I thought it might be a bad idea (PHP7.4 being the default for Debian 11, I’m afraid the reinstall took the sury/php depot instead of the debian … wondering …).
How about stopping all PHP services and deleting all socket files and than restart all PHP versions? They should be recreated than and maybe solve the issue?
Sorry but I think you are making a mistake. If you tell me to erase “sock” files, it’s in “/var/php-fpm”, there is no “/var/php”.
You mention “/var/php/7.4/fpm/pool.d” , it does not exist, it’s more probably “/etc/php/7.4/fpm/pool.d” but it does not contain “sock” files, they are all “conf” files …
So you mean I should erase “sock” files or “conf” files, which is quite different … “conf” files will be re-generated ?
Thanks for taking the time to look into my problem !
I see, I took the path from you post, but you have to check were they are.
I tried a lot of things, I had some weird results, for example stopping all PHP-fpm, if I try to start PHP-fpm 7.4 it’s PHP-fpm 8.1 that starts, weird but making sense because I discovered that those sock files were existing in both /var/php/7.4/fpm/pool.d and /var/php/8.1/fpm/pool.d…
It something I would try. The problem is quite tough what you’re having. I tried to find something to help you, but could only find someone who delete the sock files and then rebooted PHP. Maybe it will do not much for you, but worth to try.
If nothing else would work, I would backup all virtual servers, do a clean install and then restore them all. I’m not sure how long you can afford the websites to be down?
I’ll look into that, migrating virtualhosts to another server is already an option I am considering, VPS’s are now cheap enough so this can be done quite easily if needed.
Thanks for your time !
Hello,
Sorry I was real busy for a while. I made some progress … well the server made some progress because PHP7.4 did show up 2 days later without me doing anything, but … something is still weird on that server because for the last 2 days I have PHP8.0.28 showing as down on the dashboard but in fact running properly (all virtualhosts using this PHP version up and running).
If you recall my previous message I had some weird comportment (like starting 7.4 would in fact start 8.0) so I’m just planning onto completely reinstalling that machine, there is an underlying problem that I cannot isolate, so just wipe out the server and restart fresh
Thanks for your interest in my problem !
Pierre
Regarding the problem of PHP-FPM not restarting or starting after removing a domain account, it is that the file “example 1593578529637410.conf” does not have the correct permissions.
The file corresponding to the domain account “Example: /etc/php/8.1/fpm/pool.d/1593578529637410.conf” has the “root” permission and not the domain account, then when the account is removed it cannot restart by account from that.
In my case, I repeat, in my case I change the permission of the 1593578529637410.conf file for the domain account user and everything happens normally.
This cannot be right, as we delete the PHP-FPM config file while running as root.
However, what I could reproduce in my tests is that PHP-FPM pool file is not getting deleted (expectedly) if Apache website feature is disabled (disassociated), i.e. in Edit Virtual Server page.
What is odd, is that I don’t remember disassociating website features for the given, host default virtual server. @Jamie, can you think of something that could disassociate website feature by mistake?
@Jamie, no, no! I cannot reproduce it in a normal flow. However, if I create a domain with the website feature enabled and then disassociatewebsite feature for the domain, then deleting a domain makes things fail – the Unix user is getting deleted and PHP-FPM is expectedly failing to restart (if domain PHP-FPM config is not deleted).
I think we should always delete PHP-FPM config when virtual server is deleted … “just in case” … right?
Although, my issue was that I couldn’t understand the reason why website feature got disassociated. I don’t remember doing it manually.
