Everything

php

symbolic links and opcache peculiarity

php.internals

Helmut Tessarek

6 years ago

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.

Cheers,
K. C.

--
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 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.
*/

Eric Krona

6 years ago

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

Helmut Tessarek

6 years ago

On 2019-10-28 17:30, Eric Krona wrote:

> 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.

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 question
> 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 this
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.

--
regards Helmut K. C. Tessarek              KeyID 0x172380A011EF4944
Key fingerprint = 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.
*/