Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107724
To: internals@lists.php.net
References: <af224301-f152-cfb9-ef80-b1acdf9fa4ba@evermeet.cx>
Message-ID: <119c7c14-0314-94e7-ca70-a60adcec7f20@itomat.se>
Date: Mon, 28 Oct 2019 22:30:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <af224301-f152-cfb9-ef80-b1acdf9fa4ba@evermeet.cx>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: [PHP-DEV] symbolic links and opcache peculiarity
From: eric@persson.tm (Eric Krona)

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