On 19 June 2015 at 13:43, Sebastian Bergmann <sebast...@php.net> wrote:
> Scenario: nginx + PHP-FPM / FastCGI. > > The final step of the deployment is updating a symlink to point to the > new version. > > For N <= realpath_cache_ttl seconds after the deployment, some > filesystem operations fail because of outdated realpath cache entries. > > Is there a way to signal the PHP-FPM / FastCGI processes to clear > the realpath cache? If not, I think this should be added :-) > > Thanks! > Sebastian > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > (repeating on-list so it's public) While I agree that having a way to signal fpm to reset itself would be a good thing (I'm thinking something closer to the nginx "reload" op, where the config file is reloaded and all state is reset, but currently processing requests are allowed to complete before the workers are killed etc) a decent work-around is just to have two separate fpm pools and using nginx reload to do the switch instead of re-pointing a symlink. Assuming interval_between_deployments < realpath_cache_ttl, this would make the problem self-correcting. This is probably preferable in other ways too, for example you might get some weirdness if you repoint a symlink to the src in the middle of a request and some classes from the old version are already loaded, and the autoloader then gets some classes from the new version. After writing that I realise I'm not sure whether the realpath cache is per-pool, but even if it is this doesn't need to affect the model, as one could simply have two completely separate fpm instances.
