Update Status causing Drupal to run very slowly

I had the same problem: http://drupal.org/node/221100

Disabling update status module, solved the issue!

Subscribing.

hardieas - What is your network like? Are you behind a proxy or firewall that blocks HTTP/HTTPS by default, either by redirecting users to a manually configured proxy port or requiring authentication?

I have the same issue with a development box in our corporate network. Since we are behind a proxy firewall, all HTTP requests to check for updates are blocked and therefore timeout. This causes all admin pages to appear to take 10-15 seconds for each page load while the Update module is active.

On our external hosts, we have no problems as outbound port 80 is not blocked.

I submitted this bug for version 6, and dww pointed me to this post and some other hints that the real issue is with Drupal core. Drupal is not proxy aware, so all HTTP get requests are likely to hang (ex - RSS).

Same issue here - on the work network both update_status and any modules which rely on drupal_http_request() time out because of the proxy. But works fine on my home development box or on the production server.

sounds like everything here is duplicate with #172708: updating from an intranet. please see there about possible solutions for specifying proxy settings...

I've all of a sudden had the same problem.
It took me awhile to figure out what happened, because it happened suddenly and it happened to all my drupal installs at once.
I had several, 6.4 and 5.7 installs.

http://drupal.org/node/222073

http://drupal.org/node/307968

The cirtex hosting level 3 tech finally said they changed nothing. (like pulling teeth to get them to even say that)
But for all my domains to suddenly have the same problem, means something did change, outside of my installs.
Either on the host side or the update status domain.

Antonio

Not sure if this is in fact a duplicate, can someone confirm if this is happening on public/internet sites as well, not only on intranet sites?

I confirm it,

Cirtex hosting is looking into it, http://updates.drupal.org/release-history might of ended up on a ip blacklist or something.
They asked me for the domain it's using,

Just to verify, the domain that update status module uses is updates.druapl.org right?

Antonio

Just to verify, the domain that update status module uses is updates.druapl.org right?

Yes.

update_status.module starts with the following few lines:

// $Id: update_status.module,v 1.83.2.40 2008/08/14 19:01:19 dww Exp $

// Version of core that this module is currently at (and therefore,
// that sites running it must be at and will want to query for).
define('UPDATE_STATUS_CORE_VERSION', '5.x');

// URL to check updates at, if a given project doesn't define its own.
define('UPDATE_STATUS_DEFAULT_URL', 'http://updates.drupal.org/release-history');

I have this problem in Drupal 5.10 with 5.x-2.3.

Running

netstat -pan -net

shows about 50-60 connections (see a screenshot)
Module update_status wasn't running at least 10 minutes...

Can confirm that this is happening for a number of sites running on our web servers (publicly available). We have over 200 Drupal sites on the servers and response times vary as mentioned above by original poster, in our case from under a second to over 3 and a half minutes. Sites are a variety of 5.8, 5.9. 5.10, 6.4.

We've only looked at a handful (20?) of websites but they're all experiencing problems.

Regards

Patrick

+1

Any fixes? Maintainer opinions? Couldn't find anything!

...

subscribing +1

I thought that the module only checked once a day for updates. Does actually try to check for every admin page view?

Just fyi,

cirtex did something to their iptables or something. I had a level 3 tech eventually figure it out.
The weird thing was that with update status blocked on thier server, admin pages wouldn't load.

no seems to be working fine.

Antonio

a) both #329212: Update Status Module hangs admin functions in 5:10 and 5:12 and #303243: Admin pages can't be open if update_status enabled are duplicates of this.

b) i just briefly looked at the code again. here's what going wrong... as a result of #208687: Update_status claims 5.6 is insecure; wants 5.5, we refuse to use the cached data if any of the .info files have a modification time that's newer than when we last fetched data. every admin page attempts to use the cached available update data to check the update status, so that we can warn site admins on admin/* if they're missing a security update. however, if a site could never successfully fetch data in the first place, the above two facts conspire to make it so that the module is attempting to fetch data on admin/*. If it can't fetch for whatever reason, it just hangs the page and the site grinds to a halt.

i'm not sure what to do about this. :( there are a few options but none of them are ideal. we can't undo #208687 or we just trade one bug for another.

we could potentially backport #196535: Add error reporting and help text if httpd can't make outbound network connections (or parts of it) into the D5 version of update_status so that we know if we can't actually call out and handle that kind of error differently.

we could also change some of the behavior with the interaction between hook_help and all the fetching code so that hook_help never tries to fetch data, ever, and if there's no fetched data, it never prints any messages at all. we'd just leave it up to hook_requirements to bug site admins about the fact there's no available update data.

subscribing +1

Temp disabled update states on my websites. :-(

My hosting provider is asking for this information. Is there a way to find this out?

"If you could provide exact IP address and port it uses for checks, we would then create a firewall rule to allow that specific connection."

I'm running Drupal 6 on all my sites experiencing problems.

re #20: see comment #11. It's just a regular http connection (port 80) to updates.drupal.org. Using the exact IP address is hard/impossible, since updates.drupal.org is a DNS alias that points to drupal.org which is served by a number of different web hosts with different IPs, plus the web proxy host, etc, etc. Plus, the whole point of DNS is that the IP addresses might need to change at "our" end (where *.drupal.org is hosted at OSUOSL) without everyone in the world having to be told "stop going to 140.211.166.54 and start using 140.211.166.61 now".

So, if possible, tell your hosting provider to punch a hole in the firewall to "updates.drupal.org:80". If that fails, then I guess tell them "there's a web proxy and lots of webhosts -- for now, punch holes to the following but it might change later -- that's the point of DNS, you know?..."

140.211.166.6:80
140.211.166.54:80
140.211.166.61:80
140.211.166.106:80

*sigh* It seems as though 140.211.166.6 is the most important one, since that's the main proxy host, so if they put up a stink about it, try that and see if that solves it for you (for now).

Marked all of the following duplicate with this one...
#319486: Fetched update informations at every cron
#346148: Enabling update status module makes Administer menu unusable
#349375: Sometimes update_help() execute ages, Drupal freezing
#304001: "Update Status" Proyect gives "White Screen of Death" on Windows Server 2003 error, event: 1030, 1053

There seem to be a few related problems in here, but they probably all need the same solution, which is why I'm consolidating this into a single issue.

See also:
#220592: Core cache API breaks update.module: fetches data way too often, kills site performance, etc
#243253: Update status module can cause white screen if the check for updates takes too long

Those should probably be marked duplicate, too, but I'm leaving them open for now...

I have had this problem as well. At first, I thought that this was due to updating to 5.x-2.3 (with a public website). But now I suspect the latter core Drupal versions to be conflicting with 2.3.

To determine the problem, I added a watchdog statement in module.inc (when cron runs) and saw that cron was looping. After disabling update status, my site and cron went back to normal.

I solved a "Warning: MySQL server has gone away" error disabling this module.
I ask first to my hosting to enable max_allowed_packet=24M
We've tried also to run mysqli.reconnect = On;
But without good results.

Then I saw this comment: http://acquia.com/node/45684#comments
"Most often when there is slowness related to Update Status it has to do with the server blocking outbound HTTP requests."

It works fine now !! Just disabling the module

My workaround: Drupal 5.14 - Hosted in http://www.sync.es
Update Status 5.x-2.3

Subscribing, hope that helps and a solution arise

Hi,

Could it have to do with: http://drupal.org/node/222073?
It says: "After upgrading to drupal 5.14 (from 5.12) I found that under certain circumstances HTTP_HOST is not defined or sent to the drupal website.
This may affect drupal 6.8 as well, but I have not yet gotten around to confirming this.

With the latest version, the drupal_valid_http_host() function was created.
This fails when HTTP_HOST is undefined or blank."

Greetings,
Martijn

I have just upgraded from 5.14 to 6.8. This problems persists. So it must have something to do with one of the other modules, I think.

disable update status until you actually want to check on module status. On shared hosts, I've found more often than not that this is what I have to do to get drupal to react the way I've come to expect it to.

subscribing +1
Happens to my installs ov Drupal 6.8 and 6.9, mor information here:
http://drupal.org/node/360645

German thread here: http://www.drupalcenter.de/node/15393

subscribing... any status?

Yesterday, I upgraded several modules (birthday, "read more" link custamization, event, messaging, views) to the latest versions (running Drupal 6.9). After this, I enabled update status and it seems to work okay now.

subscribing - I'm all of a sudden having these issues on both Drupal 5 & 6

I'm getting this problem on a 5.10 site, and have had this problem for many months. I recently tried to upgrade a copy of this site to 6.9, and found that the same module in the 6.x version was causing the exact same problem. Disabling the module makes the delays go away immediately. I'm running several 6.9 sites on this same service provider (Lunarpages) using the Update Status module without problem. I'm only having problems with this one site that started in 5.x and when I try to upgrade it to 6.9. According to my service provider, they are not blocking any outbound IPs.

I think it may be related to some older data that is clogging up this module, but I can't figure out what. I'm going to be taking a copy of this particular site to my local dev server to see if I can identify the culprit, as I can't see the logs on my service provider. As someone mentioned above, it may be several tables/modules need to be updated, which I haven't been doing religiously, as Update Status doesn't work for this site, and I run dozens of modules.

Updated site to 5.15, updated a bunch of modules and ran update.php, still no dice. Installing update_status results in whitepages of death. I've set the PHP memory limit to 128mb, and it still refuses to load. Is there any way to get debug output on this via some other way than viewing logs? My host does not allow us to view the logs, so I have no idea what's going wrong, other than something seems to be timing out.

However, if I run the same database and files on my local dev server, I have no problems with the module. Which is unfortunate, as I was hoping to get some form of error.

asking your host to send you the logs in and around the time that your problem occured should be acceptable. If not, I'd say get a new host who allows you to get to your error logs.

The hosting service replied that running that module did not produce any error messages, nor any logged entries. I trust them about as far as I can throw them, but my own independent test was as such:

1. Duplicate the entire database to a new test database on the same server.
2. Using the same codebase, create a separate multisite version of my site using a "test" subdomain
3. Verify that the test site loaded fine, using the duplicated database
4. Enabled update_status module, noted that most admin functions became unusable, or timed-out
5. Disabled all non-core modules, except for one "Admin Menu"
6. Enabled update_status again

At this point, I was able to access most admin functions, albeit very slowly. Even the Update Status screen came up, though there were no modules listed, which wasn't right, as it should have shown me the status of Admin Menu. Clicking the "Check Manually" link produces the following error in a Drupal Status message:

Unable to fetch any information on available new releases and updates.

To me, this seems a lot like the module is unable to access updates.drupal.org. Is there any way to enable debug output so that I can verify this? I don't have shell access on this account, otherwise that would be trivial. Is there a simple bit of PHP code I could write that would prove that updates.drupal.org is inaccessible?

A bit of Googling gave me the script I needed to confirm that my host is unable to see updates.drupal.org, probably because of a blacklist or dns issue.

<?php

$ip1 = "updates.drupal.org"; // this is the host of the monitored server
$ip2 = "google.com"; // another monitored server
$onlinetext = "On-Line" ; // this is the on-line message
$offlinetext = "Off-Line" ; // this is the off-line message
$port = "80"; // this is the port that you check

if(@fsockopen($ip1,$port,$errno,$errstr,1)) {
echo"$ip1 is <a href='http://$ip1' target='_blank'>$onlinetext</a><br><br>";
} else {
echo"$ip1 is $offlinetext<br><br>";
}

if(@fsockopen($ip2,$port,$errno,$errstr,1)) {
echo"$ip2 is <a href='http://$ip2' target='_blank'>$onlinetext</a><br><br>";
} else {
echo"$ip2 is $offlinetext<br><br>";
}

?>

Just to confirm, I uploaded this script onto another server with the same provider, and was able to show both servers as "on-line". Waiting on my provider to respond to my "proof".

Update: my hosting provider discovered that updates.drupal.org had been blocked for too many outbound connections on the server in question. It would seem this module is a bit "chatty". After they unblocked this site, the update_status works fine, even for the dozens of modules I have running on this particular website.

Seems that Strato corrected whatever error it was, update-status is running fine since some weeks...

I'm having this problem, but I can't disable the update status module as I simply can't get onto the module admin page at:
admin/build/modules because of the issue. It is therefore rendering any opportunity to update modules on my site. Doesn't this essentially make this a critical problem?

Any help of how to manually disable the module greatly received! Thanks,

Adam

Hi,

You have to go into your database, into the system table, and than alter 1 to 0 for module status on update_status module row.

Greetings,
Martijn

Thanks Martijn, I found it also in the end... however it hasn't taken away the problem. Apache logs now show nothing, I just can't get access to my modules - Page not found. Its very strange...

Hi Hardieas,

For now just remove the update_status directory from your modules directory. I agree that this should be critical since it makes it unusable. It is also non-intuitive to debug.

-Marty

Hi Marty, I'm actually on 6.x - are you suggesting we should delete the "update" directory aswell? Thanks,

Adam

EDIT: Actually - I tried it and it didn't make any difference, so maybe my problem is unrelated to updates. Agh... memory set at 512Mb! So its not that... Tried everything on the Troubleshooting FAQ and still don't have access...

check your apache error log for errors being thrown?

Absolutely nothing being thrown - thats why this is driving me crazy... no php error, no mysql error and no When I disabled some modules, it worked, then I enabled one by one and it worked... then I added a new module (the task I was attempting) and it went to WSOD for /confirm. From then on it continued to go to WSOD indefinitely. It can't be memory, and it can't be this thread if I've deleted update. I should post on the forum but I'm pretty sure it'll just go to the end of the "WSOD" onslaught of issues...

Hi Adshill,

The quick and dirty way is to move the offending module out of the modules directory. Disabling it in the DB is probably cleaner.

For WSOD you may want to reference the following links that I have found helpful:

http://openconcept.ca/php_debug

http://kiribao.blogspot.com/2007/12/drupal-white-screen-of-death.html

-Marty

Thanks a lot Marty. Unfortunately most of those things were in the FAQ and others are module specific for modules I don't have. I'll keep searching though... Also its probably better we don't hijack this thread any more :) I'll post something on the forum with a wild amount of hope!

You might take a look at http://drupal.org/node/32929. There you'll find a way to print everything cron is doing. This way, I noticed that my 'update status' was looping at checking the modules.

sub

I had this fixed by my hosts - seems the php timeout value was set to 10 seconds... which was not enough time for the page to load. I asked them to increase to 30 seconds and everything came back again.

I was debugging this on another thread aswell which is where I posted my solution so apologies for delay in posting here too.

Thanks,

Adam

Hi, What is your solution specific? What do I have to change in the configuration code wise?
Thanks a lot in advance for your reply!
Greetings, Martijn

The best summary of the problem is here: #220592-52: Core cache API breaks update.module: fetches data way too often, kills site performance, etc (now committed to HEAD and DRUPAL-6 in core).

I'm going to be back-porting that to D5 contrib over at #155450: backport separate {cache_update_status} table and private non-volatile cache API from D6 core.

sub

Duplicated: #349375: Sometimes update_help() execute ages, Drupal freezing

subscribing

Just to let everyone know about my experience.

Had the WSOD on drupal 5.x and a no connect message on 6.x. Updated 'update_status' module to dev release and then no more wsod but the no connect message like 6.x. Contacted my hosting which is IX Hosting and they told me they have restricted access to this url with no explanation why and won't change it. I recommend you find a different host if you want to use drupal.

Just for the record, I had this issue with Drupal 6.15. It seemed to have started last summer, and I'm on sitegrounds for hosting. I tried upping the memory to 32M in both settings.php and .htaccess, but that didn't change a thing. Turned off update status module via phpmyadmin, and problem immediately stopped. Not sure what caused it, but I guess I'll leave the module off. Have tons of other modules installed, and might look into whether one particular one cause it, but just don't have time now :)

Cheers

Facing issues with Drupal 6.x

Subscribed, Same on 6.17

Subscribed, Same on 6.22

Please don't shift the status of contrib module reports that have been marked as duplicates to core's issue queue. Instead read this thread and follow the links provided in the comments to related discussions.

Thanks.