Bug #79005 [Opn->Fbk]: validate_timestamps only has an effect when compiling the script

Edit report at https://bugs.php.net/bug.php?id=79005&edit=1 ID: 79005 Updated by: cmb@php.net Reported by: iquito at gmx dot net Summary: validate_timestamps only has an effect when compiling the script -Status: Open +Status: Feedback Type: Bug Package: opcache Operating System: Debian Buster PHP Version: 7.4.2 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > If validate_timestamps is turned off at the time of compiling > the script for opcache, then that timestamp is set to zero, […] If the timestamp of a persistent script is 0, that means that it has been preloaded[1]. So apparently, you are using preloading, and this is only available as of PHP 7.4.0, this explains the difference to PHP 7.3. [1] <https://github.com/php/php-src/blob/php-7.4.25/ext/opcache/ZendAccelerator.c#L1096-L1097> Previous Comments: ------------------------------------------------------------------------ [2020-02-12 06:44:21] iquito at gmx dot net After validate_timestamps stopped working again I think I found the true cause. When storing a script in opcache, it sets a "timestamp" of the script in opcache. If validate_timestamps is turned off at the time of compiling the script for opcache, then that timestamp is set to zero, and the script is never checked thereafter. If validate_timestamps is turned on when compiling the script, a "timestamp" is set in the opcache data (with the last modification date of the file), and the script will be checked every time it is loaded, even if validate_timestamps is set to on after that. This was not that way until PHP 7.4 - basically, the validate_timestamps option seems to only have an effect at the time of compiling a script, after that opcache decides itself what and how it will check the file according to the value in "timestamp". I am not sure why the change in PHP 7.4, or if this is just simply a bug. When using different pools where some are with validate_timestamps and some are without, this creates some weird issues - especially when using opcache_compile_file to pre-cache files, which can then lead to all those files always validating timestamps or never validating timestamps, no matter what pool with what validate_timestamps setting is used. ------------------------------------------------------------------------ [2020-02-11 06:49:16] iquito at gmx dot net After more trials and tribulations validate_timestamps for opcache did not work at all anymore for me anymore. I have a php.ini with "opcache.validate_timestamps = 0" and overwrote that value for a testing pool in php-fpm with: php_admin_value[opcache.validate_timestamps] = 1 When I check phpinfo() it says that opcache.validate_timestamps is "On", but no script is ever reloaded when it has changed. When I set "opcache.validate_timestamps = 1" in php.ini and change it via "php_admin_value[opcache.validate_timestamps] = 0" for a php-fpm pool it seems to work as expected both for the pools which "unset" validate_timestamps and for those that do validate the timestamps. ------------------------------------------------------------------------ [2019-12-20 08:59:44] iquito at gmx dot net Description: ------------ When using php-fpm with opcache.validate_timestamps turned on and opcache.enable_file_override turned on, no script is ever reloaded in PHP 7.4.1 (it works as expected in 7.3.*). I am using the following options: opcache.enable = 1 opcache.enable_cli = 0 opcache.validate_timestamps = 1 opcache.revalidate_freq = 0 opcache.use_cwd = 1 opcache.enable_file_override = 1 As soon as I set opcache.enable_file_override to 0, then validate_timestamps works again and changes to scripts are used by php-fpm. It does not matter what kind of script you are using - in my example, I used the following: <? //echo 'dada'; phpinfo(); And then I just changed the comment to the line with phpinfo, so the page should show "dada", but that does not happen. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79005&edit=1