pm-update unusable, hangs, loops

Where is the Drupal queue table?

Nevermind, skipped right over it twice.

This indeed does fix the issue, but without this thread I'd have never solved it. Thanks.

Sorry for re-opening the issue, but IMHO this should be investigated further. Today I had the same problem and drush failed to do its job without even a suggestion on what to do - that's clearly not the thing we would expect on similar problems.

In my experience on Ubuntu 11.10 and Drupal 7, since drush 4.5 to 5-dev, "drush up" loops all the modules at least 3 times before presenting the upgrade options.

same thing happening here, drupal 7, drush 4.5 and drush v5

never mind about that guys.. i had to restart the server and now it works again.., this was Ubuntu v11 and Drupal v7

Same issue for me running Drupal 7.10 & Drush 7.x-5.0-rc2

Purging the queue table in the DB got it working again.

I agree that this issue should be looked at more closely. I also ran into the endless update loop and didn't find the solution until searching the issues.

Have the same problem, with drush 5.x-dev from March 6, 2012 - 00:14 and Drupal 7.10. I deleted all records in the queue table in the db, but the problem was not solved.

Updated to 7.12 and still the same problem.

Perhaps the same as #1420372: Modules being checked for updates multiple times.. ?

Related: #1387034: "update-code" checks module status repeatedly, doesn't end

Marked #1420372: Modules being checked for updates multiple times.. as a duplicate of this issue.

@pfrenssen #1420372: Modules being checked for updates multiple times.. is an issue for core. It seems to me this is not drush fault.

Woops I meant to do it the other way round, thanks for correcting it!

I REALLY hesitated to reopen this, but it seems the 'fix' for this in core is pretty old (last spring) yet I'm seeing this with Drupal 7.15 and Drush 5.4. I run drush up and the checking for updates just continually loops....

What am I missing? Is there a current config that could cause this behavior?

@Rob_Feature: Please run the following command and paste in the output: drush -v upc -n

Make sure you've cleared the cache_update table first, just so we can see what the full output is. Thanks.

FYI when I run the command above it does an initial check for each module first, and then re-checks the custom modules/features that did not come from d.o.

Newest Drush, newest Drupal 7.x. Every pm-update displays/checks all modules and themes in the system and outputs it to the console.

Example:

drush pm-update views

Instead of checking just Views and giving me the 'are you sure' prompt, it goes through and checks all modules, then lists what ones have an update, then asks if I'd like to update Views.

It kind of makes small module updates take a while instead of a matter of seconds, if you are like me and update a few modules at a time and verify the integrity of the application with the received updates.

The initial check is for updating the Update module's cache, if the cached data isn't available then it has to build it. Afterwards I it takes the cached data, re-checks the projects that don't have a recent status update (i.e. custom modules & features) before showing the results.

Maybe it'd be worth having an option -q to only show the projects being requested, or maybe to only scan for updates for that one project? That'd be a separate feature request issue.

I can't find the issue where we discuss writing own update status engine and not relying on core. Thats the best way forward, IMO

Ok, i just ran the command in #21 and it appeared to check most modules once, a few modules twice, and my custom modules about 4-5 times each. Then it gave the update info for each project. After this I was able to run drush up without all the checks...does this mean we just need a way to rebuild the update cache (which I assume this did?)

Rather than pasting the result I attached it (since it's so big and ugly)

I found out that it was the Drupal core function update_fetch_data_batch() that was not finishing ever. This function is called from Drush at commands/pm/update_info/drupal.inc:154

After a few attempts, it finally completed and went ahead with the next step (confirming to start the update process).

It seems that the batch operation is being called with incorrect arguments. I printed the contents of the $context variable within tupdate_fetch_data_batch() and got the following:

DrushBatchContext Object
(
    [storage:ArrayObject:private] => Array
        (
            [sandbox] => Array
                (
                    [max] => 1414
                    [progress] => 15
                )

            [results] => Array
                (
                    [updated] => 15
                    [failures] => 0
                    [processed] => 15
                )

            [finished] => 1
            [message] => 
        )

)

The max parameter has a value of 1414, while the project I am working with has less than 150. This is the reason why the process loops again and again.

Any chance you could submit a patch?

For me this behavior was caused by stale 'update_fetch_tasks' queue entries.

Once I'd done DELETE FROM {queue} WHERE name='update_fetch_tasks'; then it worked again.

(This is on [pre-core patch] Drupal 7.12, but I think it's what #28 is talking about too.)

Is this fixed in the current 5.8 - should the issue be closed?

As far as I know it is a core issue that affects Drush when it happens. The only workaround that I see is to raise a warning when the queue table has more than 200 entries. But it would be up to the developer to decide whether to truncate or not that table in order to let pm-update work correctly.

Can confirm fix in #30 did the trick. The command is lightning fast just after executing the SQL.

The second time the command is run it's a bit slower but seems to work OK.

Thanks for the fix.

Because a number of comments here reference custom modules as being checked more often, it seems this issue may be related to #934300: Update status keeps trying to fetch available updates over and over for projects without a release

Have run into this same issue, or something related to it ..

The output from running drush -v upc -n is:

#drush -v upc -n
Initialized Drupal 7.22 root directory at                               [notice]
/drupal/install/dir
Initialized Drupal site dom.com                               [notice]
Executing: wget --version
Initialized Drupal 7.22 root directory at                               [notice]
/drupal/install/dir
Initialized Drupal site dom.com                [notice]
Command dispatch complete                                               [notice]

Then it hangs endlessly after 'command dispatch complete' ..

An strace from another shell session shows it is endlessly looping doing gettimeofday() ..

I followed up suggestions made earlier, and checked the queue table, but this had zero entries .. I have now updated each module that needs upgrading via the web interface admin/reports/updates .. But still drush would not complete for this site.

I have other sites on this same host, using the same DB instance and drush update works fine with these other sites .. really puzzling, especially as nothing is being flagged as an error ..

@cnergis this is an unrelated. Please open a new issue for that.
---

#28 is yet another way to visibilize the symptom that I outlined at #1420372-2: Modules being checked for updates multiple times... No one has been able to provide consistent steps to reproduce this bug, and I haven't seen this happening for a while. Indeed I feel like it is no longer an issue since some release of Drupal 7.x. Probably since 7.13, that included #1484216: Race condition in _update_create_fetch_task() (PDO Exceptions) and #1492188: Update module creates duplicate queue items.

Similar issues here with Drupal 7.21 and Drush 5.9

Just keeps on looping. We have some modules on the site which are custom (i.e fail to get updates on D.o). I'm curious in the logic for de-queueing the updates if when one module fails to find updates it re-checks again.

When drush starts checking for updates, it also starts with a random module, not the first one alphabetically. Not sure if it's related but other sites where Drush up works it always starts with the first module in the list.

I confirm this is still a issue with drupal 7.23 and drush 5.9

- Have a previous drupal instalation on http root.
- Delete all files and install a different drupal (from a profile install) on a different database.
- Made a drush up.

Stack: nginx, php-fpm 5.5.3, mysql 5.5.x, centos 6.x

Restart boot nginx and php-fpm dont solve the issue, truncate the queue works.

Solution in #30 fixes problem for me also

#30 works for me as well.
followed by Moshe's command to list
drush up -n

I can confirm that #30 also works as well

For thos who dont know, run this:

drush sql-cli

then

DELETE FROM queue WHERE name='update_fetch_tasks';

Thanks Labboy for the detailed steps.
Confirmed #30 resolved the issue for me.

Here are the system particulars:
Shared cloud host environment on Centos 6.5/Apache 2.2/mysql v5.5.
PHP - v5.6.2
Drupal - v7.34
Drush - v6.2

Thanks, #30 resolved the issue for me too =)