-
-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
404 when using --web #209
Comments
This patch mostly succeeds with executing commands now ( 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 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
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 |
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);'
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 |
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 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. |
I am in the same boat. Even on managed vServers access to the PHP-FPM socket might be restricted and thus we cannot use |
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.
The text was updated successfully, but these errors were encountered: