FPM is maliciously compliant when asked to set opcache.preload

[greg0ire]

Description

The following FPM configuration:

php_value[opcache.preload] = /app/config/preload.php
php_value[opcache.preload_user] = app

results in phpinfo() advertising that config.

Yet when calling opcache_get_status(), there is no preload_statistics, and there is no performance improvement in the application.

I asked about this here, and was told that's because it is too late: when setting that config value, FPM has already started. If that's the case, I would expect an exception to be thrown, because I can think of a reason to allow editing that setting past a certain point

PHP Version

8.1.7

Operating System

Linux

[bix0r]

opcache.preload and opcache.preload_user are PHP_INI_SYSTEM changeable, so php_value will never change those ( https://www.php.net/manual/en/configuration.changes.php ).

@greg0ire What happens if you use php_admin_value instead?

[greg0ire]

@bix0r good thinking, but that does not appear to do the trick: phpinfo() advertises the config as changed with the correct value, but opcache_get_status() does not have the preload_statistics key. I'm inside a per-pool configuration (my file is in /etc/php/8.1/fpm/pool.d/www.conf).

I tried adding it directly in the [global] section and got Array are not allowed in the global section

[greg0ire]

so php_value will never change those

@bix0r shouldn't phpinfo() not display the setting as changed then? I think it is misleading.

[bix0r]

@greg0ire That is interesting. It seems like you can set PHP_INI_SYSTEM through php_value. I will add it to my list of strange INI behavior.

For opcache preloading I guess the pool config is parsed too late to change setting for the actual preloading. The only place for it is in php.ini.

We will hopefully, one day, end up with a proper solution that at least notifies us if a ini overwrite failed, and even perhaps why it failed.

[greg0ire]

For opcache preloading I guess the pool config is parsed too late to change setting for the actual preloading.

That makes sense, and since the preload configuration is supposed to be global (and not per-pool), I wouldn't expect it to kick in.