Each time I visit the Available updates report, all the modules are grayed out and report "No available releases found." I have to click the "check manually" link each time in order to get an update status.

However, even the update status check is inaccurate. On some checks, the reports states that "Failed to get available update data for x no. of projects." The number of failed projects varies each time the report is checked manually.

This behavior also occurs during Drush pm-update, which I assume is using Drupal's internal update tables. It takes several rounds of refreshing the update page before all module information is found.

CommentFileSizeAuthor
update_module_error.jpg100.01 KBzoon_unit

Comments

Andrew Schulman’s picture

Andrew Schulman commented

I also have this problem. Thanks for reporting, zoon_unit.

Andrew Schulman’s picture

Andrew Schulman commented

Clarification: I have the 2nd problem:

On some checks, the reports states that "Failed to get available update data for x no. of projects." The number of failed projects varies each time the report is checked manually.

and I also see the same behavior in drush. But I don't have the first problem: at Available updates, some of the update statuses are populated when I first go there.

kiphaas7’s picture

kiphaas7 commented
Version: 7.2 » 7.x-dev

sub, and bugs need to be reported against 7.x-dev ;).

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (duplicate)

I think this is a duplicate of #952394: "No available releases found" - fetching update information exceeds timeout.

Andrew Schulman’s picture

Andrew Schulman commented

Yes, seems to be.

zoon_unit’s picture

zoon_unit commented

Yes, this is definitely a duplicate. After reading the following information, I was able to workaround the problem:

This seems to be related to http://drupal.org/node/1002658 and the introduction of the 'update_max_fetch_time' variable, which is by default 5. Projects status checks are queued and this queue is only processed for 5 seconds long, so on slower connections or an unresponsive drupal.org, the queue will not be completely processed in one run.

A workaround for this problem seems to be setting the update_max_fetch_time high enough. How to set it to 30 seconds with Drush:

drush vset update_max_fetch_time 30

It appears that the update_max_fetch_time of 5 seconds is FAR TOO OPTIMISTIC and that the update process times out before the batch can conclude. Using the above drush command fixes the problem permanently and allows update to work as intended both through the UI and through "drush up."

Of course, each Drupal site would need to have this drush command run against the database.

The obvious quick, easy, and permanent solution to this problem is to increase the update_max_fetch_time to 30 seconds in Drupal 7.5.

Bug fixed. :-)

gagoo’s picture

gagoo commented

Hello,

I have the same issue on several Drupal 7.7 sites and #6 didn't solve it.

I think that it is an hosting issue because if I change my hosting to a local Xamp, the issue doesn't occur anymore.

I don't think that my hoster block the outbound traffic because the manual update status checking works randomly for 4 or 5 modules each time it is run (and don't work for all other activated modules).

So what hosting setting can affect the update status checking process ?

Thank you

Andrew Schulman’s picture

Andrew Schulman commented

gagoo, this issue is closed because it's a duplicate of #952394: "No available releases found" - fetching update information exceeds timeout. You should post your question there to have a better chance of getting it answered.

gagoo’s picture

gagoo commented

Thank you Andrew.

belalh’s picture

belalh commented
Issue summary: View changes

After a lot of research, I stumbled upon this article by Marius Cârneală.
https://www.mariusc.name/content/no-available-releases-found-drupal-erro...

His SQL command worked for me: truncate cache_update

You can also run it using drush: drush sqlq truncate cache_update