On 2019-10-24 02:03, Helmut K. C. Tessarek wrote:
I'm not sure, if this is a bug or a peculiarity with opcache, but it's
definitely not a user question thus I am poating it in internals.
I came across a weird situation today that left me dumbfounded.
I have the following symbolic link:
index.php -> ../v1/idx.php
The link index.php is in the directory /data/pr/test/, yet the file
/data/pr/test/index.php was not in the list of cached files even though I
certainly accessed the file and there's no blacklist and other files
in that
directory were in the list. This was the first strange thing, but I
thought,
hey, maybe only the real file (/data/pr/v1/idx.php) is cached.
But here's the kicker:
After I changed the sym link to point to another file
index.php -> ../v2/index2.php
I had to reset the opcache that the correct page was served.
My revalidate_freq is set to 60 seconds. I also tested different browsers,
deleted the cache in the browser, waited for more than 60 seconds, nothing
helped. Only resetting the cache solved the issue (I actually
restarted fpm).
Please let me know, if I should open a bug or if opcache just doesn't work
with symbolic links.
This is a long-standing issue with the opcache, its frequently seen when
deploying code using a symlink swap as the final step to atomically
launch the new code.
There are several pieces of information written on it, such as :
* https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/
*
https://engineering.facile.it/blog/eng/realpath-cache-is-it-all-php-opcache-s-fault/
*
https://hackernoon.com/truly-atomic-deployments-with-nginx-and-php-fpm-aed8a8ac1cd9
I have not seen a bug report somewhere to php, but its possibly a
question if it should be considered a bug or not. There are settings to
trigger a re-evaluation which the links describe, and its also possible
to call opcache_reset() for example. Most writing I've found is rather
old, but I assume its not because the problem is not there anymore but
rather that people use different means for deployment nowadays(perhaps). :)
/eric
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
