"Unable to fetch any information" on manual check

Since the last update, I've been having problems with the Drupal installation on my public site, but not on my local dev site.

Upon manual update, the public site throws the following errors:

Safari could not open the page “http://****/admin/logs/updates/check” because the server stopped responding.

and

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, webmaster@****.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

I checked Drupal's recent logs and no error was indicated, despite the consistent in ability to resolve the page after a manual update.

Yep, i confirm identical problem here too
"Safari could not open the page “http://***.com/site/admin/logs/updates/check?destination=admin%2Fbuild%2Fmodules” because the server stopped responding"
its a blank page on firefox

also started to get %2 instead of / slashes
/admin/logs/updates/check?destination=admin%2Fbuild%2Fmodule

not sure its related or not but i can not cron from modules panel

/admin/logs/updates/check?destination=admin%2Fbuild%2Fmodules

and identical message as above on blank screen
"...server stopped responding"
again not sure its related to infamous
Drupal - The White Screen of Death
http://drupal.org/node/158043
http://drupal.org/node/31819
I increased settings.php memory but ot php.ini as no access on a shared server
and .htaccess as the articles suggested
but that did not help and the blank page remains as explained above

not sure its a bug or not on the newest version of update_status.module any similar experience or pointing to a fix appreciated
thanks

This is still a problem for me. Anyone discover a solution yet? ... or perhaps even just the cause?

It would be kinda cool if the developer at least acknowledged this issue.

"It would be kinda cool if the developer at least acknowledged this issue."

- it might be reason that this issue not addressed because the issue posted as 'support' rather than a 'bug' and therefore might not be a priority... - cases like this its difficult to define as a 'bug' or the dysfunction related to something else

maybe the issue needs to re-posted as a 'bug'

no, the reason is because merlinofchaos and i are way too over-committed with too many things, and we can't always deal with every issue. plus, i was just off-line for over a week due to a sudden death in my family, and i'm still catching up on crap that piled up while i was gone.

the first thing that comes to mind is the php timeout limit. apply the attached patch and try fetching manually again. if your site is running in PHP's safe_mode, you're screwed, and will have to change this limit in php.ini. see http://us2.php.net/manual/en/function.set-time-limit.php for more.

please report back here and let me know how it goes. if this helps, we can commit a change like this to the official code.

Doesn't work for me. I can' go to available updates in logs. Cron always failed. I tried downgrade, but it doesn't help. Which leftover tables do I have to manually erase? I wanna install update status module from zero.

Just a report back

i have applied the dww's patch and i was be able manually run the cron via (something was not working before like the original poster issue here)
/admin/build/modules

but still 'check manually' on

admin/logs/updates/check?destination=admin%2Fbuild%2Fmodules
leads a (on safari, different on each browser for the same)
Safari could not open the page “http://www.movimientos.org.uk/sitio/admin/logs/updates/check?destination=admin%2Fbuild%2Fmodules” because the server stopped responding.

meanwhile i also installed a Drupal 6 beta on a testbed on a new db - to test this issue -as 'update status' is in the core of the 6 and experienced the same
admin/logs/status/run-cron
and on
logs/updates/check?destination=admin%2Flogs%2Fstatus
...could not open the page “/admin/logs/status/run-cron” because the server stopped responding.

so that might mean the problem may not lie with the Update status 5.x-2.0 and this issue will be exist on version 6 too with the 'php timeout limit'
btw- the site i test runs on PHP's safe_mode OFF

also i a not sure why i get '%2F' URL-encode for space on the URL's on cron and update links could it be part of the issue?

I got the same problem, then I found out that I got error when fsockopen() is called in drupal_http_request(). So I do a search on google and run a magic command on my server, then it works.
setsebool -P httpd_can_network_connect 1
Don't ask me why, I have no idea how it could fix my problem and I have no idea what that command does but I hope it would help somebody to understand the problem more.

@KelvinWong: very interesting, thanks for sharing. Yes, if your httpd is configured such that it can't make outbound network connections, update_status certainly can't work, since it depends on your httpd initiating a connection (to perform the http request) back to the updates.drupal.org server to fetch information about available releases. Looks like we need to put information about this into the help text, README, etc. Thanks!

Oh, and we should check the return value of drupal_http_request(), and if it failed, print a useful error message about it (and log it to watchdog()), in the hopes of informing the site admin why it's not working. I don't know if it's possible to query the httpd configuration from within php, but perhaps we could even add a check for this to the status report?

Can any of the other folks reporting this problem confirm their httpd configuration, and see if the above command solves the problem (assuming you're on a linux server)?

Thanks!
-Derek

See also http://drupal.org/node/196535 about fixing this in D6 core's update.module...

The core patch landed with more far-reaching changes. However, we could probably harvest some of that goodness and make it specific to this module. Perhaps someone wants to attempt a backport? At the very least, I guess we should add some of the text that made it into core's INSTALL.txt into update_status's README.txt.

Also, is #6 worth committing anyway, just to be on the safe side?

Ok, committed a small "REQUIREMENTS" section to the README.txt. That's all I have energy for in here.

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

I also found the message was being generated by fsockopen not resolving the DNS for updates.drupal.org This started happening after the Linux server was migrated from one IP to a new IP.

A temporary fix for Linux was to update /etc/hosts to include a static entry for

In the end, updating the nameservers in /etc/resolv.conf seemed to do the trick for good. The server can now ping updates.drupal.org and the manual update status checks are working.

we had a similar problem today.. our isp changed their dns servers and we had to update our /etc/resolv.conf files. our simplefeed curl was breaking down
and so was drupal update status check.

so we restarted our machine -
$ shutdown -r now and it worked fine.

yashesh

I installed version 6.10 today and cannot see the q=admin node. I can see all other admin nodes, although they are slow. I see a "Unable to fetch any information about available new releases and updates." in the watchdog table. Looks like my node is timing out and I'm getting a blank page. I commented some of the code to isolate the problem. This solves the issue, but of course this is not the solution (It works for me though). I'm new to drupal, but I hope this gives some ideas as what could be wrong.

module: update.fetch.inc
function: _update_refresh()
code snippet:

/*
foreach ($projects as $key => $project) {
$url = _update_build_fetch_url($project, $site_key);
$xml = drupal_http_request($url);
if (isset($xml->data)) {
$data[] = $xml->data;
}
}
*/

Thanks
Sanal

Just in case this helps anyone else who's in a similar situation;

I got a whole slew of these errors when trying to set up a new drupal install. Even more curiously they suddenly turned into success this evening.

Turns out that it was adding an /etc/resolv.conf into the chroot gaol that the webserver runs in happened to be the fix.

I'm running openbsd, so my apache runs in a chroot'd environment.

I actually wound up fixing this 'by accident' while getting mail delivery working.

Don't even get me started on the rant that php has smtp support for its mail() function if _and_only_if_ you're running on windows. SMTP is the 'right' way to get mail out of a chroot'd environment and the fact that I had to install a package (and even worse, install /bin/sh) inside the chroot to 'pretend' to be sendmail so as to throw the mails over smtp to localhost.... \end{whinge}