404 when using --web

[jonaseberle]

With the --web adapter it happens that we get 404 because it might be just too fast for some hosters to create the file and access it through the web near-instantaneously.
I guess this is related to their storage and file system caches, maybe also PHP stat cache?

Current workaround: It will usually succeed after some tries...

./cachetool stat:clear --web=SymfonyHttpClient --web-url=https://.../ --web-path=./public/ --web-host

It is currently holding us a bit back on systems where we can't use --fcgi.

Splitting this off from #199 which is about retrying the whole procedure which can probably mostly be avoided in this case.

[jonaseberle]

This patch mostly succeeds with executing commands now (stat:clear and opcache:reset).

Yet our problems (post-symlink-switching-deployment PHP thinks some files are there which are not) remain and are well described by the linked article by Julien Pauli in the README. It is about the PHP realpath cache most probably.

Yet there is one catch with what is written in that article: I do not have any problems with the realpath/stat cache on systems where I can use cachetool with --fcgi - this seems to catch all php-fpm threads. Can somebody confirm that?

Unfortunately on those 2 problematic hosters we do not have access from the web container to the php-fpm socket/port.

It can be explored by looking at

<?php
var_dump(realpath_cache_get());
clearstatcache(true);

which shows how that cache is thread-local and cache-clearing only acts on the current thread. (On some systems it is necessary to send No-Cache headers (by using CTRL+F5 to reload)).

So I am a bit at a loss here.

Should we say that not having the possibility to use --fcgi means that deployment using symlink-switching is not doable in a stable way?
Is anybody aware how someone could deactivate the PHP realpath cache?

[gordalina]

Should we say that not having the possibility to use --fcgi means that deployment using symlink-switching is not doable in a stable way?

This is very likely.

Can you run the following command and display the results?

cachetool php:eval -vvv -r \
  'return var_export([ini_get("realpath_cache_size"), ini_get("realpath_cache_ttl"), ini_get("open_basedir"), ini_get("safe_mode"), ], true);'

Is anybody aware how someone could deactivate the PHP realpath cache?

It's not a good idea to deactivate the cache, but for testing you can always set

realpath_cache_size=0
realpath_cache_ttl=0

[jonaseberle]

Thank you.

For the shared hosting in question (Hetzner Level 19) this shows:

https://gist.github.com/jonaseberle/996d2a7dc930f89b2241bdef9706c3b7

I looked into deactivating the realpath cache: Unfortunately that's not possible on that shared hosting because the realpath_cache_.. settings are php.ini only and only some select values from php.ini (plus all that are changeable via .htaccess php_value_...) are configurable.

It would of course be possible to clear the realurl cache at runtime in the application. <- This is an option we consider to do for the default 120s cache lifetime after a deployment.

[fritzmg]

I am in the same boat. Even on managed vServers access to the PHP-FPM socket might be restricted and thus we cannot use --fcgi - and --web will sometimes fail for the aforementioned reasons.