When running a 'drush cache clear' the CLI should output the user cache is not cleared and how to properly clear this.

CommentFileSizeAuthor
#20 drupal_apc_cache.inc_.patch1.01 KBsirviejo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Refineo’s picture

subscribe

R.Muilwijk’s picture

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.

R.Muilwijk’s picture

Status: Active » Fixed

Comitted to dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

a7’s picture

okeedoak’s picture

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?

bforchhammer’s picture

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...

Edit: Opened new issue for fixing this behavior: #1565716: Make "drush cc" clear cache on the webnode itself

kalabro’s picture

Does it mean that I can't use Drush successfully on the site with APC cache?

jeremyclassic’s picture

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.

mgifford’s picture

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 Murat Yılmaz’s picture

subscribing.

MrHaroldA’s picture

@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.

Orkut Murat Yılmaz’s picture

Sorry for the wrong comment. I've edited it.

fgm’s picture

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.

jeffreycai’s picture

Seems like there is no way to solve it.
Maybe there is a way to mute the warning? It is very disturbing.

MrHaroldA’s picture

@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.

dan2k3k4’s picture

dan2k3k4’s picture

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?

steveoriol’s picture

subscribing.

sirviejo’s picture

Status: Closed (fixed) » Patch (to be ported)
FileSize
1.01 KB

Here is a patch to show warning message only the first time.

fgm’s picture

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.

NenadP’s picture

I applied patch, now message feed has gone which is very useful for readibility (and I accepted that cache is not cleared :) )

fgm’s picture

Rethought this, and we have a way to make it work, I think:

  • Drush commands have access to the URL of the current instance
  • They could temporarily activate a menu entry on some URL of the site during their execution
  • Then fetch that URL with drupal_http_request()
  • The page callback would then disable the menu entry again and flush APC
  • The post_execute hook of the command could double check the menu cleanup in case something went awry and disable it forcefully
  • Alternatively, and possibly more efficiently, the URL could be always open, but use a token generated by the drush command to actually perform the flush

That way, the drush cc could indeed flush the web APC.

MrHaroldA’s picture

> 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.

fgm’s picture

Good point, but it does not change the general logic (and need for the token or dynamic enabling).

MrHaroldA’s picture

Please use this issue for clearing cache from Drush/CLI: #1565716: Make "drush cc" clear cache on the webnode itself

R.Muilwijk’s picture

Status: Patch (to be ported) » Closed (duplicate)

Discussion moved to #1565716

szymon.l’s picture

applying #20 leads to :
https://drupal.org/node/1587110
in my case, and this is not recoverable after apc upgrade...