I have a Vanilla Debian 10 server with PHP 7.4 & 8.0 installed with FPM.
2 types of packages both unlimited with 1 specifying "unlimited-8x"while the other is “unlimited-7x”, respectively pointing to the version it is supposed to run.
Scripts coded with PHP 8.0 works fine while 7.4 give an error 500. Further investigation of the error-log shows the following [Mon Jan 10 21:40:11.460703 2022] [proxy:error] [pid 1557:tid 139637490177792] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.0-fpm-sub.domain.tld.sock (*) failed [Mon Jan 10 21:40:11.460732 2022] [proxy_fcgi:error] [pid 1557:tid 139637490177792] [client xxx.xxx.xxx.xxx:0] AH01079: failed to make connection to backend: httpd-UDS
In the system configuration > webserver, i can see ALL accounts show it is running 8.0 and none running 7.4. Whereas under package, I clearly had 1 account under the package for “unlimited-php7x”.
From this i deduce that Hestia’s package manager is unable to interact correctly with PHP-FPM/FCGI which is causing this Error 500.
Please, any pointers to help resolve this is much appreciated. I dont mind https://www.buymeacoffee.com/ for fix. Since this is a vanilla server, chances are it is easily replicable and more people who is trying to use Hestia could easily be turned off by it. Not a good first impression i would say.
Personally it pisses me off that every hestiacp search i type in google returns “Did you mean VestaCP”. I can see mods here are far more active than VestaCP. But hey, that’s j me.
Fingers crossed, i really hope a fix can be found soon.
There is a bug in the default template, we currently prepare 1.5.4 which should resolve the issue. If you want to test if your issue is fixed, you can upgrade to the stagin branch of v1.5.4: 1. v-update-sys-hestia-git hestiacp staging/1.5.4
I have upgraded to 1.5.4 and it now shows this error: [Mon Jan 10 23:45:04.435056 2022] [proxy_fcgi:error] [pid 23012:tid 139637716649728] [client xxx.xxx.xxx.xxx:0] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Non-static method Misc::currentURL() cannot be called statically in /home/user/web/sub.domain.tld/public_html/folder/bootstrap.php:369\nStack trace:\n#0 /home/user/web/sub.domain.tld/public_html/folder/main.inc.php(23): require()\n#1 /home/user/web/sub.domain.tld/public_html/folder/client.inc.php(21): require_once('/home/apps/web/...')\n#2 /home/user/web/sub.domain.tld/public_html/folder/index.php(16): require('/home/apps/web/...')\n#3 {main}\n thrown in /home/user/web/sub.domain.tld/public_html/folder/bootstrap.php on line 369']
Under Settings>Configuration> WebServer still does not reflect which account is using which PHP version correctly though. I suppose this is now OSTicket’s problem, yes?
BTW, is it blasphemous of me to suggest changing the “v-commands-” to “h-commands-”. Perhaps the more we/HestiaCP differs from VestaCP, the more perhaps google will start recognizing us an entity of our own and disassociate us from trying to position ourselves as a ripoff of vesta. I get HestiaCP forked from Vesta but damn i think HestiaCP has gone quite some ways no? Or is there some unspoken rules here i am ignorant of.
Yes @eris , it was specifically enabled for that template yet under Settings>Configuration> WebServer it still does not reflect which account is using which PHP version correctly. I quadruple checked.
When this particular account was created, there was only PHP8. Ot was afterwards, that i added on 7.4. So this new error need to solved over at OSTicket’s forums? Is thar what this means?
Due to the implementation and then fact that you can have multiple php version with the same account I don’t we want to update PHP templates for each domain on update of package.
Is there anywhere on Hestia that specific extensions of php can be enabled without it being wiped out by other changes to PHP made by the control panel such as resource limits? I’m trying to enable “APCu Extension — (faster performance)” for the account that uses this 7.4 as OSTicket requires it. But judging by the supporting of the multitudes of breadths of policies and configs im worried to go directly into that php version and tweak it only to have it reset upon the next update rollout. Is this an unfounded fear or has this been addressed? What is the best way out for this matter?
