Checking for available modules fails for most of the modules

picardo,
Did you by any chance apply a patch instead of doing an actual version upgrade of Drupal? this can cause that to happen.

I was having the same problem this morning. It would only get the results for a few modules, but most came back with the error that it failed to fetch available update. I checked over and over again with the same results. Then all of a sudden it decided to work and got a result for all of them. I hadn't changed anything, so I'm not sure why it's doing this. Seems to be random.

Also, for the record, I did the full upgrade, not the patch.

Having the same problem... Here is what I tried
- Checked with my host to see if they closed port 80 to outgoing http requests
- updated all modules
- uninstalled all modules and reinstalled them one by one
- switched to garland (thinking it might be a script problem)
- installed the site locally using MAMP and it worked just fine

I need help... I am running out of hair to pull out...

Seeing the same issue. This seemed to happen during the upgrade from from 6.12 to 6.13.

I'm having the same issue too. I did a full upgrade, from 6.12 to 6.13, but the site seems to work find on my local machine, but on my live server it doesn't work (see attached jpegs). I contacted my hosting (mediatemple) and they reassured me that port 80 was open, so at this point i'm not sure if it's drupal 6.13 or my server. Could it be something to do with it timing out? I also wonder if it was my php memory, but I have it set quite high, to 128mb. Has any one got this resolved yet?

Very odd, after a week or two of not being able to fetch the update information...it started working for me last night.

I've the same problem

My hoster confirm that port 80 was open and they don't change anythink at server configuration.

I never had any problem before the last Drupal upgrade.

Has any one resolved this problem ???

Same problem. It doesn't seem to be localized to any specific module. Running update.php doesn't help either. Checking manually for updates yields different results on different attempts. One manual check will yield some "failed to fetch errors", while another manual check will yield "failed to fetch errors" on different modules.

I think the xml returned by updates.drupal.org is broken.

There are lots of those entries:

<term>
<name>Projects</name>
<value>Modules</value>
</term>

Seems to work again.

Marking as fixed then.

This problem still appears to exist. I'm getting two results for update. One result says "Unable to fetch any information about new releases or updates" with an entirely blank list below it. The other result is a list of the files checked, with "Failed to fetch available update data" next to each (including core drupal 6.15) except for one that does succeed. That module is advanced forum 6.x-1.1.

"Available Updates" (admin/reports/updates) gets the empty list.
"Check Manually" (admin/reports/updates/check) gets the filled list with the forum module success.

Same problem just started to occur. I get the empty list through all methods. Watchdog reports "Unable to fetch any information about available new releases and updates."

When I run cron I receive the "Failed to fetch available update data" error message" response.
I then click on "available updates" and most of the displayed modules indicate "Failed to fetch available update data warning".
This is on a dedicated server of which I have complete control. I removed all firewall controls with no positve effect.
There are Four seperate drupal sites running on this server. Each with it's own dedicated database. One site is running drupal 6.15 and the other three 6.16.
No logged changes have been made to the server environment or to three of the four Drupal sites.
The only common thread is that the Administration module is the only module in each case that indicates that it is Up to date. This is the first module in the list. Very weird.

Correcting status. Needs work applies to patches.

Btw. is this really a bug report? This seems to be more of support request to me...

And why isn't this a dup of the core issue mentioned here: http://drupal.org/node/663564#comment-2389634 ?

Hallo
I have some new info that might shed some light here.

I have the same problem and it is blocked by my firewall.
It seems that when you press Check for Updates drupal generates a lot of DNS requests and it is blocked by the firewall.

This is from vuurmuur_conf (Active) Connection Screen

128: DNS firewall(Internet) -> global.inet ESTA OUT <- 25 k 8 k -> 174.143.xxx.xxx -> 72.3.128.240:53 (17)

128 is the connection count
174.143.xxx.xxx is my servers IP address in the Rackspace Cloud
72.3.128.240:53 is the IP:Port for Rackspace Cache DNS server for their Cloud Servers service.

5.x seems unaffected.

The way i see it the DNS requests are way too many for a site with 53 modules.
By the way the first 43 manage to get the update report which means 128 connections are generated from only these 43 modules. The rest get blocked.

Hi,

my Hoster told me that the problem are to many connections to one address at one time. The update module should use "keepalive" to minimize the connections.

They raised the limit for updates.drupal.org and master.drupal.org so it works without fixing the update module.

Subscribe.
Same issue, some times the first module gets checked (admin menu) most times nothing.
Network Solutions
One D6.14, two D6.17's on a small shared.
One D6.17 on a lagre shared.
Read several posts on this issue, tried everything, NS says port 80 is not blocked and they have no blocked ip list. Nothing in any of the other posts seem to apply. Is there a way to test to find out EXACTLY where the breakdown happens?
Thanks--
Al

I'm having the same issue. I tried various PHP configurations , increased socket time out , disabled firewall , etc but nothing helped so far.
Note that the exact same site work well on an online server

This is actually a support request. Nothing we can leverage here.

There are *so* many possible server configurations that *could* cause trouble for update status. We can't code for all of them. Closing this issue (while trying to clear out the update.module component of the core issue queue)...

I know this is set to 'closed (wad)' and all, but I am still having this for quite some time now. I initially tried posting at #575044: "Failed to fetch available update data" at /admin/reports/updates, but after reading through this issue here it seems to be the place to subscribe for any possible future solution. Here's a copy-paste from my post to the other issue (in hope that'll some of the questions I asked there will be answered here):

I've been having issues in at least 5 different setups (really-low-traffic sites + all on personally controlled servers over simple aDSL lines) using 3 different ISPs. I admit that this only seems to happen when the amount of modules in each setup is quite large + most of the times I also check for updates on disabled ones. I've had this issue for far too long without reporting anything, but now I got tired of having this issue where only some of the modules/themes are retrieving update info and the rest of them simply display 'Failed to fetch available update data'. I was not sure if this belongs here or in Drupal core under the 'update system' or the 'update.module' component, so please enlighten me...

Some times I need to click the '(Check manually)' link several times before finally receiving update info for all of them. Some of the times even after this persisting manual check there'll be one or two of them still not receiving update info. This is frustrating!

So, I need to ask: what happens if during the whole checking-for-updates procedure something goes wrong and no update info is retrieved? Does it try a second or third time or does it simply fail gracefully? Is there any setting someplace that I somehow missed so that I can force it to keep trying every while for the modules/themes it failed? Anyone aware of any feature request filed for this?

Thanx in advance and sorry for the question attack ;)

...all my setups with the issue are latest 6.19 (so I'm switching the issue to that version) with most -if not all- of the modules & themes to their latest dev versions. I'd also like to note that I am not having this issue with any of my test 7.x test installations on the same servers.

Some extra info that match other people's reports in previous posts and thus make me believe my issue belongs here (in the future I kindly ask people to check their issue against this list so we can track this down):

1. Low traffic site(s) on a dedicated line (so timeouts are likely not an issue - if one knows of a benchmark or a way to test this please let us know).

2. php memory at least 128MB (so running out of memory should not be the cause either).

3. No firewall blocking the traffic. Again, a decent test to ensure that this is not the issue is welcomed.

4. Happens on various IPSs.

5. The issue occurs for various modules/themes - not the same one(s) each time. This kinda rules out a single defective module causing the issue.

This seemed to be the most recent thread that was relevant to problems I experienced when upgrading several modules (not the Drupal core) so I wanted to post my solution in case others come this way (even though the issue is closed).

After updating a couple of modules I was getting a "Failed to fetch available update data" message for the last four of my installed modules in my module list (as viewed in /admin/reports/updates). When I saw that error message I tried checking manually for updates (link at the top of the /admin/reports/updates page). I noticed after checking manually I had received a message from my hosting provider (KnownHost) that

lfd on host.mydomain.com: 140.211.166.21 (US/United States/master2.drupal.org) blocked with too many connections

I signed into my WebHost Manager and added the IP address to a list of allowed IPs, and then when I ran the manual update checker in /admin/reports/updates I no longer got the "Failed to fetch available update data" message.

Subscribing. Come on, it was working without problems earlier, after some Drupal update started problems - in the beginning I haven't seen results for a few modules, and it was getting worse by time. Now I can see results only for 16 modules, and the rest (about 50 of them) are gray with message "Failed to fetch available update data".

If you can't check what is source of this problem, how about enhancing error message with more details about reason of the problem? If it is a connection problem or memory problem or script timeout?

I was having the same problem. When I checked the Available Updates Report page, about 50% of my modules were showing the following error message:
"Failed to fetch available update data"

What was more worrisome was that, when I tried to check for updates with Drush, the modules that were not getting update information on the website were not even being recognized as being installed on my website! The faulty modules were invisible as far as Drush was concerned.

I found the solution to the problem on my server but I am not sure if this is a one-fits-all solution.

1) Let me start by explaining how the problem started:
When I went to my server I logged in and ran Drush as the root user. I know that logging in as "root" is not good but I am lazy. Sue me! :)

After each module update, I needed to go to the modules folder and run "chmod" & "chown" to recursively set the permission back to 775 and give ownership back to the "apache" user. The last time around I forgot to do it. As a result, even though only 3 modules needed to have their permissions fixed, these faulty modules caused Drupal to skip a bunch of others that were perfectly fine.

2) The solution:
After logging back into my Linux Dedicated Server and resetting the permissions to the way they were supposed to be, everything worked again on the Drupal Reports page as well as in Drush update.

Following is how I did it:

a) First you will have to login to your Server with a "ssh" client such as "Putty" as root, so you can change permissions, and open the folder where your website is located:

[root@myserver.com ~]# cd /etc/www/html/myserver/

b) Now you need to enter into the folder where your modules are installed:

[root@myserver.com myserver]# cd sites/all/modules/

c) Now let's change the permissions on every module:

[root@myserver.com modules]# chmod -R 775 ./

d) Now you will need to give the ownership of the modules to your apache user. Just make sure that you know your apache user name. On my Dedicated Server it is called "apache" but it could be different in a different setup:

[root@myserver.com modules]# chown -R apache:apache ./

This problem can also be caused by different circumstances. If, for example, your server is not properly configured and you upload a module with an FTP client, the folders will be owned by the FTP user that you used to login to your server. If Apache doesn't have permissions to access folders created by your FTP user, you will end up with the same problem.

This problem can be fixed through your Web Hosting Control Panel as well. Each Control Panel has a different way of going about it. If the problem happens again when you are using your FTP client, you should contact your Web Hosting Server Administrator to configure the permissions correctly so apache will have access to the files that your FTP user creates.

My hope is that this solution will help someone out there in the Drupal community.

Last time I checked up on this issue was two years ago. Since then I've been having the issue with almost all my D7 setups. It occurs sporadically and it is resolved if I persist a couple of times on the "Check now" link in the "Available updates" page. Never tried drush so I can't tell. Anyways, I don't think we're getting anywhere by having this be a support request.

I update my modules through WinSCP upload/extract and the login is as root (sue me too). 99% of the modules in my setup show user 6226 (apache) as the owner but I guess that's the permission the .tar files have set before packing or something. The rest few modules have root as owner, but these are either custom modules or downloaded from git (sandbox modules for example). The issue does not seem to "prefer" either of these groups of modules, so I don't think that the owner or folder/file permissions in general have anything to do with this. I'm guessing it must be more of a timeout issue or something.

I don't know if I was clear enough in my previous post so let me give a second stab at it.

When you check for updates, Drupal makes a list of the modules to check for update and goes over each one in a specific order. As soon as it finds the first one that has permission problem, it just stops checking for the remaining modules. All of the remaining modules are the ones that get error messages. It doesn't matter whether the remaining modules have permission problems or not.

I don't know exactly in what order Drupal organizes the modules before running the update task. It doesn't seem to me that Drupal orders them alphabetically. Drupal could be ordering them by the weight of each module as it is set on the "system" table on the database. Drupal could also be going through them in the order in which each module was installed. That's why, when the modules are listed in alphabetical order on the reports page, the modules that show error message seem to be so random.

Hello world,

I had the same problem in all my sites in my account, in all sites another accounts same hosting I have access. As I could understand, the source of problem is timeout of connection to Drupal updates server. I am insert in node string

<?php
<?php print_r(drupal_http_request('http://updates.drupal.org/release-history/userdelete/7.x?site_key=wu5EoI8foK0l5R0wPfaMB2WXZUznbUprQlmzSx_8fEM&version=7.x-1.0&list=userdelete'));?>
?>

(for example)
And I resive
=> -60 [error] => Operation timed out )
As temporary resolving 'no cheking updates', in core file update.module in string define('UPDATE_MAX_FETCH_ATTEMPTS', 2) I change 2 to some bigger (only in one site). Cheking updates begun works in almost all projects (but not all, checking time was extremely long).
Via SSH, I check traceroute's, ping's, wget's from my hosting server to Drupal updates server - visually everything was fine.
After 1,5 monts the problem disappears in all my sites and nothing was changed in tracerouts, etc.

So I thing, the source the problem is Drupal updates server.

If you use the HTTPRL module, this could be a culprit. It was in my case.

https://www.drupal.org/node/2653544

#32 - Thanks, it is my case too with HTTPRL.

The error repeated.

I flushed cache_update table, it resolved the issue.

(https://www.drupaleasy.com/quicktips/drupal-7-check-available-updates-so...)

And the error still repeats :-(

It seems that upgrade Drupal core to 7.51 removes this bug. Please confirm.

I am using Drupal 7.51 and just experienced this issue.
Tried truncating cache_update but still returned the HTTP ERROR 500.

This only started happening after updating to D 7.51. Also updated to PHP 5.6.27 if that has any bearing on this.

Edit:
this seems to be functioning again.

I got this issue after Upgrading from 7.50 to 7.52. But only on two installations on one special server. I've updated about 10 other installations on other servers (shared and dedicated hosting) without that effect.

Truncating cache_update table helped. But only if I use the "Check manually" link inside the admin UI. drush ups for example run into the fail state again.

After upgrading a site to 7.52, I'm noticing that "Check manually" will run until it hits the modules and themes in the disabled list, then it fails. Something appears to be wrong with the update routine. It's not ignoring disabled modules and themes. Truncating the cache_update table does not help, nor does anything else in this thread.

UPDATE: I uninstalled and totally removed all of the modules and themes listed as "disabled." I cleared the cache, ran cron, then checked for updates manually. I got a mostly positive result, but some modules were still listed as "Failed to get available update data." I checked for updates manually again, and this time everything was checked and verified as updated.

I have fetch same issues and I have fixed it using following patch files.

Hi all,

Please let me know are you using file_entity module in your setup. because today I updated it with latest release 7.x-2.27 and update is start working fine,

also, user a better server with 32GB RAM, with 156module (core and contributed)