Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <55840E5D.1090809@php.net>
References: <55840E5D.1090809@php.net>
Date: Fri, 19 Jun 2015 14:32:38 +0100
Message-ID: <CAGAGxbaCCwC_vVNW8-XW9F+b-06fHC3hmPL0iGCinwnjxfB64A@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04182626295fbe0518def58d
Subject: Re: [PHP-DEV] PHP-FPM: How to clear the realpath cache on deployment?
From: cw@daverandom.com (Chris Wright)

--f46d04182626295fbe0518def58d
Content-Type: text/plain; charset=UTF-8

On 19 June 2015 at 13:43, Sebastian Bergmann <sebastian@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.

--f46d04182626295fbe0518def58d--