syntaxseed, 10 months ago

Definitely seems to be an opcache issue. And setting opcache.revalidate_path=1 in the global php.ini settings works.

However this server is managed by Runcloud and I'd rather not override their config. Will have to test more with it set locally in php.ini within the app.

contortion, 10 months ago

@syntaxseed

Depending on what you're deploying with you could clear the opcache with a command like service php-fpm reload on the server after the releases are switched.

michael, 10 months ago

@syntaxseed that also seriously impacts performance in my experience (though how seriously probably depends on your setup / traffic levels / etc). Which is why I’m suggesting to reload php-fpm during deployment if you can.

sebobo, 10 months ago

@syntaxseed the PHP realpath setting could help, checkout this blog post https://sandstorm.de/de/blog/post/realpath-cache-in-depth-or-fixing-a-tricky-neos-deployment-issue.html

Or you flush the PHP opcache, which should also help.

michael, 10 months ago

@syntaxseed not usually dealing with apache, but I usually restart php-fpm during each deployment, just to be sure opcache doesn’t mess things up

scanton, 10 months ago

@syntaxseed maybe 'apache graceful' helps you after you publish the new release files

josh, 10 months ago

@syntaxseed @grmpyprogrammer A best practice is to just soft-restart apache upon deployment. You're probably experiencing the PHP opcache.

syntaxseed, 10 months ago

@josh @grmpyprogrammer I agree. I think this is it. But I'm trying not to need root for my deploy script. Still investigating but getting closer!

josh, 10 months ago

@syntaxseed @grmpyprogrammer You can clear the opcache from a php script without needing root. You’d need to be smart about how you protect it, but you could just create an opcache_reset.php in your document root that calls this function and hit it with curl or something. https://www.php.net/manual/en/function.opcache-reset.php

omerida, 10 months ago

@syntaxseed @josh @grmpyprogrammer something related to symlink deploys turns up on internals too: https://externals.io/message/107650#107725 seems like it relies on realpath cache: https://engineering.facile.it/blog/eng/realpath-cache-is-it-all-php-opcache-s-fault/

willpower232, 10 months ago

@syntaxseed @josh @grmpyprogrammer I have a similar situation from years ago and the only solution I found was to allow the user sudo powers only for reloading php-fpm 😬

syntaxseed, 10 months ago

@josh @grmpyprogrammer

Found the best way was a local webapp override which is found in another location (for servers managed by Runcloud) and setting opcache.revalidate_path=1 solved it.

barbanet, 10 months ago

@syntaxseed Is something special being used for cache? Maybe OpCache?

fsniper, 10 months ago

@syntaxseed I haven't used apache for a long long while so I can't talk about the behaviour. However I can suggest a "touch symlink" to update the modified time of the symlink.