To me this is not a bug. We depend on opcache.file_cache as a second level fallback cache used when PHP-FPM is restarted, so that even when opcache in memory is empty, the first hit will be from file cache.

If opcache_reset is changed so that the files in opcache.file_cache is emptied every time PHP-FPM is restarted, that would be very bad, as it would defeat the purpose of having opcache.file_cache as second level fallback cache.

Also you can set opcache.revalidate_freq=0 (like we have done), so that the timestamp is checked for every updates on every request, that way you will never get code from outdated cache objects.

Also, if you update PHP every month with a new PHP version, then the entire directory for file_cache get a new name/number, and you simply delete the old directory after each PHP upgrade.

I ask that the current behavior is not changed, as we very much depend on having opcache.file_cache as a second level fallback cache, so that first request when opcache in memory is empty, is from the opcache.file_cache

The documentation for opcache_reset() clearly states: "reset the entire opcode cache. After calling opcache_reset(), all scripts will be reloaded and reparsed the next time they are hit."

In contrast to the docs, opcache_reset() does not clear the entire opcode cache, and post at minhost dot no is using this bug as a feature.

Probably either one of us does need a more adjustable opcache_reset() mechanism (flush everything, flush only memory, flush only outdated hash directrories from file cache, flush entire file cache) or an option to have opcache_reset() only flush specific parts of opcache (with a configurable default).

> Also you can set opcache.revalidate_freq=0 (like we have done), so that the timestamp is checked for every updates on every request, that way you will never get code from outdated cache objects.

Revalidation does only check for changed files, but is unable to remove objects from cache whose source has been moved or removed - those files stay in the file cache. And with every PHP version, a new hash directory is created, resulting in a new copy of the cache. Unless the file cache is manually purged, a lot of cruft does accumulate in the file cache. A cache should be managed automatically and not rely on someone manually removing files.

> Also, if you update PHP every month with a new PHP version, then the entire directory for file_cache get a new name/number, and you simply delete the old directory after each PHP upgrade.

If the "freshness" of a hash directory were known, opcache_reset() invoked after an update could also remove the file cache for the outdated hash directories.

Manually removing file caches is a workaround I'm certainly not happy with.

> To me this is not a bug. 

it is

> We depend on opcache.file_cache as a second level fallback 
> cache used when PHP-FPM is restarted

irrelevant! when you say "reset cache" you mean exactly that

This is related to an open report from 2016: https://bugs.php.net/bug.php?id=71749

Also experiencing the same issue. What's the official method to clear the memory & file cache so that changes are detected by opcache, without a race condition of manually deleting cache files?

Duplicate of bug #75670.