Remove auto generation htaccess AddHandler application/x-httpd

[bonny3]

Good morning,
I ask for instructions to disable the auto generation of the htaccess file on my site
now this problematic string is added

<IfModule mime_module>
AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
</IfModule>

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.
#<IfModule mime_module>
# AddHandler application/x-httpd-ea-php72 .php .php7 .phtml
#</IfModule>

and add this line:

AddType application/x-httpd-php .php .htm .html

 

[cPanelLauren]

You can't delete or stop the auto generation of that file. It should be managed through the MultiPHP Manager in your cPanel interface.

 

[bonny3]

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

Thanks

 

[cPanelLauren]

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.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php74 .php .php7 .phtml
</IfModule>
# 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-FPM

 

[bonny3]

Hi,

this is my Mime Types:

application/x-httpd-php

php php3 php4 php5 php6

.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 recur

 

[cPanelLauren]

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?

 

[bonny3]

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?
[/QUOTE]

/home/username/logs/

why if i disable the string in htaccess does the problem disappear?

 

[cPanelLauren]

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.log

 

[bonny3]

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

[/QUOTE]

this is the file you indicated to me

does not allow me to send the file,
I send you the screenshots

 

[cPanelLauren]

Pretty sure that's enough:

PHP :: Bug #74709 :: PHP-FPM process eating 100% CPU attempting to use kill_all_lockers

bugs.php.net

This is from a plesk article but it's 100% relevant to your issue:

• The PHP-FPM versions 5.6 and 7.X causes such behavior and restart of the PHP-FPM service fixes the issue.
• Some websites are downloaded instead of displaying the content.

Are you using opcache? Per some other bugs from PHP I'm noticing a trend with the module causing issues: 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

 

[bonny3]

Pretty sure that's enough:

PHP :: Bug #74709 :: PHP-FPM process eating 100% CPU attempting to use kill_all_lockers

bugs.php.net

This is from a plesk article but it's 100% relevant to your issue:



Are you using opcache? Per some other bugs from PHP I'm noticing a trend with the module causing issues: 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

if opcache is running,
what advice can you give me to solve the problem?

disable opcache or add kill_all_lockers command?

I raised the children...

Thanks

 

[cPanelLauren]

I'd say first try disabling opcache and see if that resolves the issue for you.

 

[bonny3]

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?

 

[cPanelLauren]

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 https://raw.githubusercontent.com/php/php-src/PHP-7.2/NEWS

 

[bonny3]

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 https://raw.githubusercontent.com/php/php-src/PHP-7.2/NEWS

I'll keep an eye on the log
and I will inform you to tell you which is the ideal solution

Thanks for your assistance

 

[bonny3]

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 https://raw.githubusercontent.com/php/php-src/PHP-7.2/NEWS

Hi cPanelLauren,

I confirm that the problem is "opcache",
after disabling "opcache" there were no more errors in the log nor the generation of the .php file
at this point who needs to be informed to fix this bug?

Thanks
Best Regards

 

[cPanelLauren]

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?

 

[bonny3]

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?

perhaps the problem can be solved by disabling
"kill_all_lockers" (I have not tried)
but I don't think it's the definitive solution but only temporarily
if I disable kill_all_lockers it won't work anymore

to make it work properly now I am without opcache
for this reason I ask you how to solve the problem

 

[cPanelLauren]

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.

 

[bonny3]

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?