Can't seem to switch php handler to fcgi.
So we wanted to make use of httpd and stop using mod_ruid and instead remove php 7.3 and use mpm_event instead of prefork.
Also we wanted to use Fastcgi (not fcgid) as php handler.
To do this we configured easyapache accordingly.
Still when I go to the Multi PHP manager I only have the choice between cgi and none.
If I remember, there was something in the log which I clicked away too fast. Something about 2 workers were present which was not possible, event and prefork (while that one I had disabled) and event was stopped.
Also httpd2 could not be found.
I presume there is a log, but I don't know where that is. How can we fix it so we can choose fcgi from the php handler menu?
Also, at this time we got so many saved profiles, we would like to clean them up so the oversight gets a bit more clear. However it seems we can't delete any easyapache profiles from the easyapache page.
Only "customize" and "provision".
So how can unused/older profiles be really deleted, same with the selection choice of old php 5.x versions?
-
Hey there! If you go back into EasyApache and use the "customize" option, it would tel you if there are any handlers that would be in conflict, and give you an option to adjust that. As far as the profiles, you can only remove custom profiles and not the system defaults, which is likely why you don't see that option. There's an older feature request for this at 0 -
Some sites did not work anymore, throwing error so I had to put back the previous backup. So might have indeed been the php handlers which were causing the issue. I had started the customize option again to check this, but it did not state any conflict. It did when I changed the handler, but it automatically disabled the old handler and mod_ruid2 (because I selected mpm_event too). But it looked as something has went wrong during provisioning. Set everything back and now the sites throwing error 500's are running again. I already upvoted the feature request in the past. I didn't remember the directory mentioned there to manually remove the profiles. However, would be much nicer and easier if the root admin could just select them from the GUI and then select delete. Thank you for being willing to bring that up again during the meeting. So something must have gone wrong during provisioning, but I think we only are going to try again after the holidays, to be sure everything keeps running for now. Oh yes, last question, if we are going to run php-fpm with fastcgi, will .htaccess files still be able to be used? Is htscanner installed automatically or something? Or do we even need htscanner for this? 0 -
.htaccess will still work well. It might be a good idea to submit a ticket to our team when you are ready to try that switch again so we can see what's going on with the system and help you avoid potential downtime on the sites. 0 -
Oh that would be nice. I'm normally doing things like this at night time (around 01.00 GMT+1) to prevent disturbing customers. Maybe next time I can better first disable the conflicting stuff, then use the provision and then change to mod_proxy_fcgi and mpm_event and then provision again instead of letting cPanel do it all automatically? 0 -
Our team is around 24x7, so time doesn't matter to us. We can even try and schedule the ticket to be checked during a certain time for you if that would help. 0 -
That would be great, thank you for the offer. I'll give it another try early next year and if it doesn't work again, then I will make use of the offer. Thank you very much. 0 -
Sure thing! 0 -
For 1 and 2, yes, just open a ticket. For option 3, the tools are still experimental but our team would be happy to take a look at that for you and see if there is anything that would keep that from working well on your system. 0 -
Thank you very much. As for 3 I asked that since I see a lot of automatic backups from profiles going on, which are stating about conversion to Almalinux 8. Which made me things the tools were already quite stable. But if the tools are experimental, we might better wait a bit for that as Centos 7 is not end of support yet and maybe end of the year the tools might be improved. Or otherwise in a year maybe the owner wants to get a new server. I will shoot in a ticket then this week for 1 and 2. Thank you! 0 -
The big reason to get off CentOS 7 at this point is PHP 8.2 support, as we don't plan to release that for CentOS 7. 0 -
Ah oke, good to let me know. However, we will not be using anything higher than php 8.1 for the time being on that server. But it's good to know in case something comes up, thank you. 0
Please sign in to leave a comment.
Comments
12 comments