The PHP .user.ini not being loaded in Ubuntu 20.x

Two thoughts come to mind.

1. Did you restart Apache?

2. Check directory/file/user permissions to make sure they’re set to what is needed.

 1. Did you restart Apache?

These per-directory .ini files not a feature of the mod_php/mpm_prefork configuration.

At:

https://www.php.net/manual/en/configuration.file.per-user.php

it says:

PHP includes support for configuration INI files on a per-directory basis. These files are processed only by the CGI/FastCGI SAPI.

So, this feature is only available if you are using php-fpm. So, @LouWestin's question should be

1. Did you restart php-fpm?

Check directory/file/user permissions to make sure they’re set to what is needed.

Ownership should be www-user:www-user. Permissions for directories should be 0766 (-rwxr-xr-x). Permissions for files should be 0644 (-rw-r--r--).

-- sw

I don't think I'm running php-fpm, at least I can't find any reference to it anywhere… via a 'status' command, etc.

I did find that in order to use .user.ini it must be 'permitted' in the php.ini file. Here is what mine shows:

;;;;;;;;;;;;;;;;;;;;
; php.ini Options  ;
;;;;;;;;;;;;;;;;;;;;
; Name for user-defined php.ini (.htaccess) files. Default is ".user.ini"
;user_ini.filename = ".user.ini"

; To disable this feature set this option to an empty value
;user_ini.filename =

So it looks like .user.ini would work. BUT, in the doc link that Steve Wi sent it says:

.user.ini files
PHP includes support for configuration INI files on a per-directory basis. These files are processed only by the CGI/FastCGI SAPI. This functionality obsoletes the PECL htscanner extension. If you are running PHP as Apache module, use .htaccess files for the same effect.

So that is that. Thanks.

I don't think I'm running php-fpm, at least I can't find any reference to it anywhere… via a 'status' command, etc.

php-fpm(8) is it's own process separate from apache2(8). It has to be started, stopped, etc separately from apache2(8). This allows you to make PHP config changes without restarting apache2(8). Also, mod_php is Apache-only. If you switch to ngnix or lightspeed, you're going to be required to switch to php-fpm(8).

What does

ps -ef | grep php

say? If it's nothing, you are NOT runnning php-fpm(8). You really should be though…you could prob get some more performance out of a multi-threaded MPM (mpm_event or mpm_worker) AND a multi-threaded php-fpm(8). mod_php is not thread-safe so it only works with mpm_prefork.

All you have to do to switch is (this is for mpm_worker…works the same way with mpm_event):

• disable mpm_prefork (sudo a2dismod mpm_prefork);
• disable mod_php (sudo a2dismod php);
• enable mpm_worker (sudo a2enmod mpm_worker);
• enable mod_actions, mod_fastcgi, mod_alias (sudo a2enmod actions fastcgi alias…you may have enabled some of these already);
• enable the php-fpm(8) configuration (sudo a2enconf php-fpm);
• start php-fpm(8) (sudo systemctl start phpX.Y-fpm…X.Y is your PHP version);
• restart apache2(8) (sudo systemctl restart apache2)

The conf for php-fpm(8) is found under /etc/php* somewhere. It's highly configurable. Since it's multi-threaded you can segregate PHP requests for different sites into different thread pools, etc so they can be handled most efficiently (for better throughput).

See:

https://www.garron.me/en/blog/apache2-mpm-worker-prefork-php.html

https://www.digitalocean.com/community/tutorials/how-to-configure-apache-http-with-mpm-event-and-php-fpm-on-ubuntu-18-04

mpm_prefork/mod_php is so 1980s! ;-) One of these days, mod_php is going to go away… Doing this now will future-proof your installation.

-- sw

xxx@yyyyy:/var/www/html$ ps -ef | grep php
xxx 4921 4910 0 17:33 pts/0 00:00:00 grep --color=auto php

I'll take a look at all the docs you sent. My websites are low volume and are targeted to a small audience… for example https://radioqsl.com

I might get 50 hits a day… on a good day!

Thanks. Linode should put you on the payroll for the great job you do here for "the rest of us."

I might get 50 hits a day… on a good day!

That doesn't obviate the need for future-proofing your site. I tells ya…mod_php is going to go away…sooner rather than later. It comes from the PHP folks, not the Apache crew.

-- sw

P.S. php-fpm(8) works perfectly fine with mpm_prefork.

I tells ya…mod_php is going to go away…sooner rather than later.

Couldn’t agree more. It also gives you the freedom (should you wish) to change from Apache to any other FastCGI-capable web server, such as Nginx.

I get around the same traffic as you, and made the switch to PHP-FPM about 3-4 years ago, and to Nginx probably about 18 months ago.

Separating out your sites into pools in PHP-FPM also allows you to track which site is hogging resources - which is something you never know you need… until you need to know it!