New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
command cache clears itself and doesn't rebuild #79
Comments
|
We need 'Steps to Reproduce'. Feel free to attach an archive-dump of a Drupal site if thats needed to reproduce this. |
|
It seems to happen intermittently, but I'll try and monitor it more carefully. I'm afraid I can't really upload a DB dump of a client site! |
|
This appears to be a problem with Drush 6.0+ as reverting to Drush 5.8 solved the problem. |
|
This also happens intermittently for me. I run into this problem with: |
|
If someone can reliably reproduce this, it would be great if they could also create a drush archive-dump and either post that online or send it to me personally. Thats needed to get to the bottom of this. |
|
I'm having the same issues. I'm using 6.1.0 and features 2.0. I haven't found a way to reliable reproduce this. |
|
Can it be related to https://drupal.org/comment/4673100#comment-4673100 ? |
|
Even if it takes a few tries, I'd be interested in someone archiving their site and sending it to me (or posting here). Just use the archive-dump command. I will keep trying to reproduce the bug and then fixing it. |
|
I thought I could reproduce it by installing features module and a custom feature in the profiles directory, but it did not work. I will see if I can find the minimum requirements in a bare Drupal installation to reproduce it. |
|
I've got a site I can reproduce this on with Drush 6.2.0, but it's not a bare Drupal install (but, pretty close). It looks like what's happening is that the md5 for the cache files isn't matching. For example, grepping for
As files that match. I'm not familiar with what drush is using exactly to generate those hashes, but it seems like a good place to start. |
|
I figured this out at least for our specific case. We're using a patch from https://drupal.org/node/1617860 that adds support for profiles/all. In includes/command.inc, on an empty cache, "profiles" is scanned for files: https://github.com/drush-ops/drush/blob/master/includes/command.inc#L1413 However, once we have a cache file, we don't scan /profiles, causing a different cache key to be generated, and losing features.drush.inc. Can anyone reproduce this without patching in support for profiles/all? |
|
I've yet to test this on a clean install, but on the site I'm working on at the moment we had ldap_authentication module enabled but not configured. This was raising a PHP notice. Disabling ldap_authentication appears to have resolved the issue for now. |
|
Also experiencing this issue. Unfortunately the site is large, complex, and confidential - so I can't give you a sample DB. Still, here's my debug output in case it helps: When I checkout the 5.x branch it's fine. This is 6.x only. |
|
@weitzman , I've contacted you via d.o with an archive-dump as requested. I've experienced the issue with multiple projects when using Drush 6.x. Using 5.9 I do not encounter the issue. Hope the archive helps! |
|
Thanks @tannerjfco for the archive. In his case, the problem was that he had 3 profiles in /profiles and had modules enabled from each of them. Drupal only recognizes one profile, which is stored as install_profile in the variables table. A Drush speed opimization is that we sometimes only look for drush commandfiles in the active profile. So drush commands can go missing if they are not in that folder. So, Drupal supports modules coming from inactive profiles but thats arguably a mistake-feature. If Drush could find a way to support this and stay fast, I'm willing to do so. Folks sufferring from this bug could disable command caching or move the commandfiles that go missing to sites/ dir or to the active profile dir. |
|
@weitzman could you explain how to disable drush command caching (preferably only for one site)? For now I worked around the issue by placing the needed module in the /profiles/standard folder. |
|
Great! Thank you for the resolution this far. I have definitely encountered this problem in sites which only use the default install profile, and where nothing to do with the active profile has changed before it started happening. Maybe that needs a separate issue opened. Either way, I'll post back when I find an example. @weitzman it might help if you lay out how you arrived at that conclusion - ie how you debugged the drush bootstrap - so that others on this thread might be able to self-diagnose? |
|
+1 The feature module to be reverted is located in: The behavior: Interesting, let's clear the cache - Whoa! Let's try again, just for kicks No luck, search the web, find some interesting comments about updb first No database updates, an error - yet now cache clear works - hmmmm Voila! Definitely weird, would love to have this work predictably. Sorry, I can't send you an archive of the site. |
During bootstrap, we guess at which commandfiles to load from /profiles when the current command is not bootstrapping past DRUSH_BOOTSTRAP_DRUPAL_SITE. Unfortunately, we were doing this guessing always, not just for those special commands. This patch moves the guessing to within a conditional as it was before I introduced the bug in ac51e27. This should also make Drush a bit faster for sites that have big /profile directories that have many disabled modules. Backports efdd5ac.
|
Puh, we ran into the same problem with Drupal 8.5.4, Features 8.x-3.7 and Drush 8.1.14. Annoying. Doesn't work: drush updb -y
drush fim team -y
>> Command fim needs the following extension(s) enabled to run: . [error]Work: drush updb --cache-clear=0 -y
drush cr -y
drush fim team -y
>> Current state already matches active config, aborting. [ok] |
joachim-n commentedSep 11, 2013
It seems that various operations cause drush to forget its commands.
See https://drupal.org/node/1653222 for various user experiences with this.
The text was updated successfully, but these errors were encountered: