symbolic links and opcache peculiarity

  107650
October 24, 2019 00:03 "Helmut K. C. Tessarek" <tessarek@evermeet.cx>
--lZuUzLwsa6KSYmYrR6gLJTqo5dXdTkWWM
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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 t=
hat
directory were in the list. This was the first strange thing, but I thoug=
ht,
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, nothin=
g
helped. Only resetting the cache solved the issue (I actually restarted f=
pm).

Please let me know, if I should open a bug or if opcache just doesn't wor=
k
with symbolic links.

Cheers,
  K. C.

--=20
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint =3D 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/


--lZuUzLwsa6KSYmYrR6gLJTqo5dXdTkWWM--
  107724
October 28, 2019 21:30 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
  107725
October 29, 2019 00:01 "Helmut K. C. Tessarek" <tessarek@evermeet.cx>
--kKuANBtToohbNwrdVP2YARBD6HFPceNPQ
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2019-10-28 17:30, Eric Krona wrote:
> This is a long-standing issue with the opcache, its frequently seen whe= n=20
> deploying code using a symlink swap as the final step to atomically lau= nch=20
> the new code.
Thank you very much for your reply. However, in my case I was not really deploying something, but I get your point.
> I have not seen a bug report somewhere to php, but its possibly a quest= ion=20
> if it should be considered a bug or not.
Yep, this is the question I hoped would be answered on internals.
> There are settings to trigger a re-evaluation which the links describe,=
> and its also possible to call opcache_reset() for example.
This is just a workaround, which I used anyway. If the culprit is a combination of opcache and realpath caching, it should still be mentioned= somewhere in the docs. In my case, it was rather an edge case and I usually would not run into t= his problem. It is something I have noticed though, and I hoped I'd get some feedback = from the developers. Thanks again for the reply and the links. Cheers, K. C. --=20 regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint =3D 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ --kKuANBtToohbNwrdVP2YARBD6HFPceNPQ--