Reset cache via terminal/command line

[schickling]

There should be a way to reset the cache for any php instances (CLI/FPM...) via the command line. Just running php -r 'opcache_reset();' doesn't work yet

More workarounds and discussion:
http://stackoverflow.com/questions/17716639/opcache-clean-cache-in-php5-4-and-lower/

[TerryE]

There is a way to do this as I've described on the SO thread. This is due to an architectural constraint of how OPcache works. Consider the multiple Vhosts example where your server is running dozens of separate UID hierarchies. Each UID would have its own cache -- which cache would your cli call connect to?

This isn't an OPcache issue really in terms of current or road-mapped functionality, so can I suggest that you close this issue. Thanks.

[schickling]

Thanks again for your response and help.

Perhaps you can see this issue as a feature request for a simpler way to achieve this?

[TerryE]

Most accelerators bundle in some form of management GUI and IMO adding one to OPcache would be a good feature. Another SO Thread mentioned this one: PeeHaa/OpCacheGUI.

[dstogov]

We won't provide command line interface.

It's possible to reset cache calling opcache_reset() from a PHP script accessed through HTTP.

e.g.

Put the following file into your web root.

opcache_reset.php

then call it using command:

wget http://127.0.0.1/opcache_reset.php

It's also a good idea to protect this file with password or limit it's usage to localhost only.

[schickling]

@dstogov That's exactly what I did but feels like a workaround to me. But its ok for now.

[czapeczek]

Do you have any reasonable explanation of not providing the commandline feature ?
IMHO making a cache-flush tool only from web access is a mistake

[laurinkeithdavis]

@czapeczek I agree - in fact, I created a page that just resets the cache - when my cache is having trouble (see my other open issues), this page crashes when I open it (because the cache is crashing), yet the cache is now cleared. We really need a way to clear this that is not tied to the webserver itself.

[rlerdorf]

The reasonable explanation is that the shared memory segment is anonymous and only accessible from the process that created it. There is no way to write a command line tool that can access it. Therefore, if you cache_reset web script fails, your only recourse is to restart your web server.

[laurinkeithdavis]

Ok, well, I can see that, but do not agree that the current method is far from ideal?

[rlerdorf]

The alternatives are worse. If you do not make it an anonymous mmap segment then you have to worry about orphaned ipcs which you would manually have to clean up in order for the server to work at all. And I have never encountered the case where I couldn't run my admin script.

[laurinkeithdavis]

I guess that depends on your definition of "working." :)

My admin script will give me a 500 error when Opcache is failing for #127. It does reset the cache, but I can't tell (meaning, I just have to hope that it's working due to the 500 error.)

[rlerdorf]

Ah, Windows. Not my thing. Sorry.

[czapeczek]

I am bothering with this because my deploy procedure is now

1. Automatically deploy code
2. Go and reset the cache / now it will be run wget http://{...}

With the wget, my worrie is that everyone will be albe to clear the cache until I provide a token at least and i just don't like such solutions. Thanks for the feedback

[rlerdorf]

Normally the way you solve this is in the web server config. You restrict it to only allow access to that reset script from localhost and you make hitting that script part of whatever local deploy mechanism you run. You could also fix your deploy strategy to not need a cache reset, of course. eg. http://codeascraft.com/2013/07/01/atomic-deploys-at-etsy/

[TerryE]

@czapeczek, @laurin1, as Rasmus says, this isn't unsatisfactory. To me this is a bit like expecting the IP layer to include TCP support: here we have an architectural constraint that is simply addressed by adding an additional simple management tier.

As to access control and preventing "everyone" being able to reset the cache then there are many standard ways of preventing this. One simple example is that your CLI script and the web script are both under your control and can therefore use a shared secret making it practically impossible for 3rd parties to compromise the system -- unless of course they have already compromised it to the extent that they can access your PHP source, in which case they've possibly got access to your databases, etc.

Whatever you think this isn't an issue with OPcache as it's currently scoped and this issue should remain closed. At best this is an enhancement request which doesn't belong here.

[muhqu]

FYI: I was searching for a solution to call opcache_reset() for a specific php-fpm process running.

And I found a way of doing so using cgi-fcgi to directly comunicate with php-fpm without requiring a webserver to be involved.

#!/bin/bash
echo '<?php opcache_reset(); echo "ok\n";' > /tmp/php-fpm-opcache-reset.php;
SCRIPT_FILENAME=/tmp/php-fpm-opcache-reset.php \
REQUEST_METHOD=GET \
cgi-fcgi -bind -connect /var/run/php5-fpm.sock;
rm /tmp/php-fpm-opcache-reset.php;

[muhqu]

...just to iterate on the idea I have just created php-fpm-cli which allows stuff like:

php-fpm-cli -r 'opcache_reset();' -connect /var/run/php5-fpm.sock
# or
php-fpm-cli -r 'var_dump(opcache_get_status());' -connect /var/run/php5-fpm.sock

[chrisLeeTW]

@muhqu : thanks for your solution, it's really helpful. because it's not only resolve the opcache clear issuse and also reslove how to do health check of php-fpm that without web server !

thanks again!

[muhqu]

@chrisLeeTW I'm also using it to monitor apcu metrics. works great so far. ;-)

[girvan]

@muhqu php-fpm-cli is awesome and it also solve my several problem, thank you.

[ghost]

php-fpm-cli worked for me as well, cheers!

[alexVauch]

@muhqu your script is awesome! Thank you.
Also for those who get message such as: /var/run/php5-fpm.sock not found but the file exists. Check the file permissions. Your user should have permissions to read the file.

[terraboops]

If you're using mod_php running inside of Apache, you can run this from the command-line:

service httpd reload
or
apachectl graceful

This will gracefully restart Apache -- it should cause no disruption for connected users.

[sir-gon]

@muhqu works like a charm!!! perfect for my continuous integration setup...
For debian 8 jessie requires the libfcgi0ldbl package to get the cgi-fcgi command working inside the script.

[diegonalvarez]

@muhqu thanks ! Awesome script, works for me in my first try.
Best regards.

[fmonts]

For those who get the

cgi-fcgi: command not found

error, you have to

apt-get install libfcgi0ldbl

[muhqu]

…and for those on RHEL/CentOS:

yum --enablerepo=epel install fcgi

[szepeviktor]

See https://github.com/gordalina/cachetool

[jeffmcneill]

Note that the following will all clear opcache:

apachectl -k stop + apachectl -k start
apachectl -k graceful
apachectl -k restart
apachectl -k graceful-stop + apachectl -k start

The second and fourth options are gentle with connected users.

More about the apachectl commands here: https://httpd.apache.org/docs/2.4/stopping.html

[TerryE]

apachectl -k graceful-stop + apachectl -k start

So does reboot, but neither option is sensible for a production service, is it? Wrapping up a php opcache_reset() call in an authenticated access script or one of the other patterns discussed above is a far sounder approach.

[jeffmcneill]

Please explain why graceful-stop + start is not a viable approach. It is made for such circumstances.

[TerryE]

OK, this is a personal view, but the 2.4 graceful stop / restart is a lot better than a normal stop in that it
allows Apache to bring its child processes to an orderly exit so the you can then restart everything. However, from a queueing perspective what this does is to collapse the overall webserver throughput during the bounce. This is fine for services with a light transaction rate, or where request rates have a diurnal cycle and you want to do a release or some other S/W activity which requires to the bounce the caches during "quiet" hours. It has the great advantage that it allows all child processes to bounce their caches synchronously. But this is some way from what control engineers would class as a "bumpless handover".

[jeffmcneill]

I don't see how there is a throughput collapse wiht apachectl -k graceful-stop + apachectl -k start. That doesn't make sense. One process stops responding to new requests while a new process starts responding to new requests. But if you don't like that, then just go with apachectl -k graceful which is what its namesake suggests. The same apache process reloads a new configuration (including a new opcache). With a multisite configuration, it seems that one has to have an opcache flush command run against each site, whereas at the level of the webserver, this can be done in one place at one time.

[TerryE]

I think that you are trying to describe the apachectl -k graceful function which is a graceful restart (Signal: USR1 not WINCH), though even this has worker brownout issues according to some of the comments. PHP is usually built in none-threaded mode, and uses a lot of child workers.