When running a 'drush cache clear' the CLI should output the user cache is not cleared and how to properly clear this.
The webserver and the client run in different memory segments. So it's not possible to clear the APC cache using drush. You can use different methods for clearing the cache.
1) Use the clear all caches in the Drupal website.
2) Setup the apc.php script somewhere on your webserver to clear the cache. Use `locate apc.php` to find it on *nix.
Comitted to dev.
Automatically closed -- issue fixed for 2 weeks with no activity.
This has to be one of the most annoying error messages ever. Most Drush commands return the error multiple times. How do I turn OFF the message?
I agree. When I run drush cc all I get the message like 60 times...
drush cc all
Edit: Opened new issue for fixing this behavior: #1565716: Make "drush cc" clear cache on the webnode itself
Does it mean that I can't use Drush successfully on the site with APC cache?
No, you can use Drush on APC enabled sites. However, the messages produced by the Drush / APC combo are annoying and only point back to this post, not a solution.
Note: despite the annoyance of the messages, APC really is the best working caching solution for me and Drush is the best way to get monotonous maintenance tasks done with Drupal, so, a little inconvenience in a "best of breed solution" is, unfortunately, acceptable.
So no solution yet, but where is this problem getting worked on?
Is it with the memcache module? drush? memcache itself? php?
Would be good to have some hope that in a few months we won't have to deal with these annoying messages.
@Orkut: the 7.x-1.0-beta4 already includes this (very annoying) message.
See #1565716: Make "drush cc" clear cache on the webnode itself for the follow-up.
Sorry for the wrong comment. I've edited it.
The problem is with the fact that the Drush (CLI) PHP instance does not address the same memory segment as the one used by the PHP server SAPI in use, so any action it can take, assuming apc.enable_cli is on (it is off by default) only affects its own segment and not the one in use by the PHP server. So the only way to really perform a cache clear from the CLI is to connect to the webserver, assuming proper credentials (which cannot be guessed, since the password is hashed), and trigger a server-side clear.
Seems like there is no way to solve it.
Maybe there is a way to mute the warning? It is very disturbing.
@jeffreycai, the warning is there for a reason: your cache isn't cleared. The only way to clear your cache (atm) is by clearing it from your website (admin/config/development/performance).
This will be addressed somewhere in the future, hopfully soon.
I'm getting the same as others but for every drush command I do.
So performing an install of a new module causes the output of 100+ lines of just:
cache_bootstrap(variables) was not cleared. APC cli uses a different memory storage then the webserver. For more info see: [warning]http://drupal.org/node/1278232
Any way to fix this or mute/move the warning elsewhere?
Here is a patch to show warning message only the first time.
Just an idea: maybe the built-in server in PHP 5.4 is using the same APC segment and could be used in that case ? Just an idea before I forget it.
I applied patch, now message feed has gone which is very useful for readibility (and I accepted that cache is not cleared :) )
Rethought this, and we have a way to make it work, I think:
That way, the drush cc could indeed flush the web APC.
> Drush commands have access to the URL of the current instance
I tried that already, but when a site is in maintenance mode, Drush has no access (HTTP Error 503 - Service unavailable). That's why I use XMLRPC instead of a menu callback.
Good point, but it does not change the general logic (and need for the token or dynamic enabling).
Please use this issue for clearing cache from Drush/CLI: #1565716: Make "drush cc" clear cache on the webnode itself
Discussion moved to #1565716
applying #20 leads to :https://drupal.org/node/1587110
in my case, and this is not recoverable after apc upgrade...
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.