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
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
I think this is a symptom of doing deploys incorrectly.
You are right, of course. Thank you for pointing out this layer 8
problem :-) No clue why I did it different (read: stupid) for a
private project when I know better. Oh, well.
On Mon, Jun 22, 2015 at 9:26 PM, Sebastian Bergmann sebastian@php.net
wrote:
I think this is a symptom of doing deploys incorrectly.
You are right, of course. Thank you for pointing out this layer 8
problem :-) No clue why I did it different (read: stupid) for a
private project when I know better. Oh, well.--
another alternative is using absolute paths everywhere:
http://grokbase.com/p/php/php-internals/133qxh5ndm/php-dev-continuous-integration-atomic-deploys-and-php-5-5
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hello, internals!
I remember the crazy code for invalidating the opcache/realpath entries
from CLI.
Logic was the following: tool asks for the server name with php-fpm to
connect to via ssh connection, then it prepares a small PHP-file and
uploads it to the temp directory on this server and then connects directly
to the php-fpm socket on this server via FCGI protocol (implemented in PHP)
to issue an request to this temporary file. So, it's possible to access all
shared variables/states in this php-fpm instance.
After that it's possible to execute a command in the context of server.
This can be used for invalidating the realapth/opcode cache. Hope, that
this information can be useful for you )
Thanks
2015-06-22 23:27 GMT+03:00 Ferenc Kovacs tyra3l@gmail.com:
On Mon, Jun 22, 2015 at 9:26 PM, Sebastian Bergmann sebastian@php.net
wrote:I think this is a symptom of doing deploys incorrectly.
You are right, of course. Thank you for pointing out this layer 8
problem :-) No clue why I did it different (read: stupid) for a
private project when I know better. Oh, well.--
another alternative is using absolute paths everywhere:
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu