Not in white list. Check listen.allowed_clients about cachetool HOT 14 CLOSED

I found out that this is maybe a fastcgi client library problem (adoy/PHP-FastCGI-Client#13)

It's seems that adoy/PHP-FastCGI-Client is not in actively maintained. maybe change a fastcgi client library is good idea ?

from cachetool.

@gordalina hi, can you do a release with this fix please and place it to http://gordalina.github.io/cachetool/downloads/cachetool.phar? Thank you.

from cachetool.

Yeah, looks like someone forked adoy/PHP-FastCGI-Client into https://github.com/hollodotme/fast-cgi-client
If you're interested in sending in a Pull Request to switch libraries, I'd be happy for it

from cachetool.

I've switched from adoy/PHP-FastCGI-Client to https://github.com/hollodotme/fast-cgi-client and scripts invalidation works now! 🍾 See PR above.
However I did it only for 3.x branch as we use PHP 7.0.

I also added this change to my PR as well: #94

P.S. Seems like tests failed because of bad build configuration (something wrong with GitHub token)

from cachetool.

What's your listen.allowed_clients value in your php-fpm server?
From which machine are you invoking cachetool?

from cachetool.

@gordalina There is no explicit configuration for listen.allowed_clients, which - according to the PHP documentation - means it should accept all. Additionally, we only use unix sockets for our FPM pools, not TCP sockets.

Cachetool runs from the same machine, and uses the same socket as we use for our webserver.

from cachetool.

If you run cache tool after the error it works? How many times does it error before it works?

from cachetool.

Running it immediately after usually works

from cachetool.

We also faced this problem from time to time.

our listen.allowed_clients value is 127.0.0.1
and listen value is 127.0.0.1:9000

so maybe this problem is not completely relative to listen.allowed_clients

and our php version is also 7.0 & os version is Ubuntu 16.04

from cachetool.

Same problem for me. Sometimes I am getting same error

from cachetool.

For us mostly it occurs during deployment when flushing opcache it increases the load quite drastically and cachetool prints out this error, i think it's because of timeout that occurs in the underlying library that is executing the flush operation through FPM. It ends up succeeding but we get the error and can't suppress it or handle it so the build fails. Due to the high load it just takes longer for FPM to respond, ideally an option to change the timeout could also work

from cachetool.

I'm also hitting this problem.

Migrating to https://github.com/hollodotme/fast-cgi-client seems like a solid idea.

What's stopping merging #96?

from cachetool.

One of the big problems I'm experiencing is that after this failure, phpinfo() shows that PHP opcache becomes disabled and I have to restart the interpreter to restore it. Very costly. Does anyone here have any thoughts?

from cachetool.

My problem was highly likely caused by a WordPress plugin calling opcache_reset() due to Redis object cache not being properly invalidated Yoast/wordpress-seo#9315

from cachetool.