Remove auto generation htaccess AddHandler application/x-httpd
Good morning,
I ask for instructions to disable the auto generation of the htaccess file on my site
now this problematic string is added
AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
Occasionally the site crashes when I load the domain into the browser,
and download an empty PHP file, to restart it I have to
restart the service PHP-FPM Service for Apache
Why is this happening?
I had to delete this line:
# php -- BEGIN cPanel-generated handler, do not edit
# Impostare il pacchetto "ea-php72"" come linguaggio di programmazione "PHP"" predefinito.
#
# AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
#
and add this line:
AddType application/x-httpd-php .php .htm .html
-
You can't delete or stop the auto generation of that file. It should be managed through the MultiPHP Manager in your cPanel interface. 0 -
You can't delete or stop the auto generation of that file. It should be managed through the MultiPHP Manager in your cPanel interface.
Hi, Can you explain better what I should do to solve my problem in cpanel MultiPHP Manager ? explain to me if my problem with the blocking of the site and the downolad of the empty php file is due to this string? AddHandler application/x-httpd-ea-php72 .php .php7 .phtml Thanks0 -
So if this is configured with the right PHP version you should never encounter that issue. That string isn't really the issue or literally everyone who uses cPanel would be experiencing this issue. What I would advise instead is to look at the php-fpm logs for the user to identify why the crash is occurring. What's added when I select PHP version and mime types through the MultiPHP Manager is the following addition (I'm using php 7.4 but it should make no difference): # php -- BEGIN cPanel-generated handler, do not edit # Set the "ea-php74" package as the default "PHP" programming language. AddHandler application/x-httpd-ea-php74 .php .php7 .phtml # php -- END cPanel-generated handler, do not edit
If your PHP version and Mime Types are properly set in the MultiPHP Manager (and cPanel>>Advanced>>Mime Types) the generated AddHandler should be sufficient. This is the same with or without PHP-FPM0 -
Hi, this is my Mime Types:
.php7 and .phtml are missing I have to add? Could this cause the problem? I checked the php-fpm logs but no problems are highlighted However, by eliminating that string, the problem does not recurapplication/x-httpd-php php php3 php4 php5 php6 0 -
I have: application/x-httpd-php php php3 php4 php5 php6 application/x-httpd-php-source phps
If nothing is noted in the php-fpm logs - why is it crashing then? That doesn't make a lot of sense, there should be something noted there. What log are you looking at?0 -
If nothing is noted in the php-fpm logs - why is it crashing then? That doesn't make a lot of sense, there should be something noted there. What log are you looking at?
/home/username/logs/ why if i disable the string in htaccess does the problem disappear?0 -
why if i disable the string in htaccess does the problem disappear?
That's literally what I'm trying to help you find out. But I can't if you're not providing all the information necessary. Those should absolutely not cause that issue - As I've shown you, I have it on my own test server with and the same configuration with no issues, which leads me to believe there is more to the story. Furthermore, if this was indeed the actual cause of the issue - none of our users' sites would work. Obviously PHP-FPM is crashing - my personal belief is that is what ultimately is causing your issue. Identify the cause of the crash and most likely identify why this is occurring on the site./home/username/logs/
The logs you're looking in are usually where I'd direct you but as they're just for issues specific to that user I believe you'd want to look in the global logs themselves. You can find the error log here:/opt/cpanel/ea-php$$/root/usr/var/log/php-fpm/error.log
so if you're using php 7.2 you'd look in the following location:/opt/cpanel/ea-php72/root/usr/var/log/php-fpm/error.log0 -
so if you're using php 7.2 you'd look in the following location: /opt/cpanel/ea-php72/root/usr/var/log/php-fpm/error.log
this is the file you indicated to me does not allow me to send the file, I send you the screenshots0 -
Pretty sure that's enough: PHP :: Bug #76482 :: opcache + MPM ITK might cause apache2 to halt You also can copy and paste output into codeblocks here which eliminates the use for screenshots. I noticed at the very bottom as well that the pool for that user reached it's max children setting - i'd suggest increasing this as well at WHM>>Software>>MultiPHP Manager -> System PHP-FPM Configuration MultiPHP Manager for WHM | cPanel & WHM Documentation 0 -
Pretty sure that's enough: PHP :: Bug #76482 :: opcache + MPM ITK might cause apache2 to halt You also can copy and paste output into codeblocks here which eliminates the use for screenshots. I noticed at the very bottom as well that the pool for that user reached it's max children setting - i'd suggest increasing this as well at WHM>>Software>>MultiPHP Manager -> System PHP-FPM Configuration
0 -
I'd say first try disabling opcache and see if that resolves the issue for you. 0 -
I'd say first try disabling opcache and see if that resolves the issue for you.
if I disable this function "kill_all_lockers", what problems could I have?0 -
So I don't know much about it but from what I am reading it looks like it's specific to this issue - I don't know that it will cause issues. There were issues with restarting opcache with it enabled (it wasn't being recognized as being in disable_functions) but it looks like that's been resolved per 0 -
So I don't know much about it but from what I am reading it looks like it's specific to this issue - I don't know that it will cause issues. There were issues with restarting opcache with it enabled (it wasn't being recognized as being in disable_functions) but it looks like that's been resolved per
0 -
So I don't know much about it but from what I am reading it looks like it's specific to this issue - I don't know that it will cause issues. There were issues with restarting opcache with it enabled (it wasn't being recognized as being in disable_functions) but it looks like that's been resolved per
0 -
I'm glad to hear that it's resolved without disabling the AddHandler :) I think there's some confusion - this is related to the bug that is linked earlier in the thread: PHP :: Bug #74709 :: PHP-FPM process eating 100% CPU attempting to use kill_all_lockers why would you need to open another bug report? 0 -
Based on that case, the problem is the CPU usage caused by PHP-FPM when kill_all_lockers is called - from what I understand OPCache is what's initiating that call. The bug is not actually OPCache's problem though, it's PHP-FPM's and that case is the correct one, no further ones should necessary. Until PHP resolves that issue it'll remain a problem. The options are either kill_all_lockers or stop using the module that's initiating that call - the only other alternative is stop using PHP-FPM in favor of another handler. 0 -
Based on that case, the problem is the CPU usage caused by PHP-FPM when kill_all_lockers is called - from what I understand OPCache is what's initiating that call. The bug is not actually OPCache's problem though, it's PHP-FPM's and that case is the correct one, no further ones should necessary. Until PHP resolves that issue it'll remain a problem. The options are either kill_all_lockers or stop using the module that's initiating that call - the only other alternative is stop using PHP-FPM in favor of another handler.
from what you tell me the problem is PHP-FPM but are they aware of the problem? that's what I'm saying ... I didn't have the CPU problem, but a blockage of a process that could not be killed ... How can I report this to anyone who manages PHP-FPH?0 -
PHP-FPM is managed by PHP they are already aware which is what I'm trying to tell you. I'd wager that you do indeed have a CPU problem when PHP-FPM crashes 0
Please sign in to leave a comment.
Comments
20 comments