PHP-FPM: How to clear the realpath cache on deployment? View as Markdown

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

--

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

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 :-)

I think this is a symptom of doing deploys incorrectly. If you are
flipping a symlink on a live server which can happen in the middle of a
request then your deploy mechanism is broken.

The web server should set the document_root to the target of the symlink
at the start of a request.

For nginx this is a built-in feature:

fastcgi_param DOCUMENT_ROOT $realpath_root;

For Apache I wrote a module to do it: https://github.com/etsy/mod_realdoc

Then there is never a question of needing to clear any caches at the PHP
level.

See: https://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/
for a more indepth explanation.

-Rasmus