After years without problems, update_status doesn't work anymore. I noticed it first because my cron didn't complete for more than two weeks and finally traced the problem to update_status.

I've already tried removing/reinstalling the update_status module (both 5.x-2.3 and 5.x-2.x-dev). As soon as I enable it, I get the white screen of death for ANY admin/ page (normal site content still works fine). Nothing else has changed in the configuration in the two weeks since the module stopped working.

I've seen the WSOD mentioned in connection with the update URL being blocked by the web hoster (#222073: Update Status causing Drupal to run very slowly), but I've tried manually accessing it from my server with wget http://updates.drupal.org/release-history/ and that works without problems. Any other ideas on how to track the problem down?

This is on Drupal 5.19 with Apache/1.3.41 (Unix) mod_ssl/2.8.31 OpenSSL/0.9.8j PHP/5.2.9 mod_auth_pam_external/0.1 FrontPage/4.0.4.3 mod_perl/1.29

Comments

rene_w’s picture

rene_w CreditAttribution: rene_w commented

Meanwhile I updated to Drupal 5.20 and also tried the update_status 5.x-2.x-dev 2009-Oct-06 snapshot. Still no luck; every time I enable update_status, I get the WSOD.

I've asked my web hoster if they made any changes, but no.

I've tried debugging the WSOD but all the resources I found on Drupal WSOD debugging are about how to find the module causing it. But I already know it's update_status, so what next? How can I find out what's wrong inside update_status? There's nothing at all in the watchdog log or the Apache error or access logs.

Config: Apache/1.3.41 (Unix) mod_ssl/2.8.31 OpenSSL/0.9.8j PHP/5.2.11 mod_auth_pam_external/0.1 FrontPage/4.0.4.3 mod_perl/1.29

rene_w’s picture

rene_w CreditAttribution: rene_w commented

Great conversation, here...

Updated to Drupal 5.21 and still have the same problem. Everything else works as always, except enabling update_status still leads to a WSOD for all admin pages.

Am running out of ideas how to track this down -- nothing in error or access logs, just an error in the browser after waiting a while

An error occurred while loading http://my.site/admin/settings/update_status:
Connection to host my.site is broken.

Also tried to increase the max execution time in my .htaccess, but that didn't help, either:

  php_value max_execution_time              259200
  php_value max_input_time                  259200
  php_value session.gc_maxlifetime          1200

Any help? Anyone?

hass’s picture

hass CreditAttribution: hass commented
Status: Active » Fixed

Higher your max memory setting in php.ini e.g. 36MB, 48MB, 64MB

Status: Fixed » Closed (fixed)

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

patcon’s picture

patcon CreditAttribution: patcon commented

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

rene_w’s picture

rene_w CreditAttribution: rene_w commented

Memory is set to 64MB.

Meanwhile I found out that there is a hard limit on php execution time on my shared web hosting (30sec), but that's not the cause, either -- I get the WSOD well before the timeout limit (after ca. 10sec).

rene_w’s picture

rene_w CreditAttribution: rene_w commented
Status: Closed (fixed) » Active
patcon’s picture

patcon CreditAttribution: patcon commented

10 seconds bang-on for me too rene :)

From all the topics I've read, it definitely seems to be a shared hosting issue...

markpenny’s picture

markpenny CreditAttribution: markpenny commented

I have 96 MB. Admin pages return when Update is disabled.

helloswetal’s picture

helloswetal CreditAttribution: helloswetal commented

I updated to Drupal 6.16. Every time I enable update_status, I get the WSOD.

I've asked my web hoster if they made any changes, but no.

I've tried debugging the WSOD but all the resources I found on Drupal WSOD debugging are about how to find the module causing it. But I already know it's update_status, so what next? How can I find out what's wrong inside update_status?

jbfelix’s picture

jbfelix CreditAttribution: jbfelix commented

Ihave the same problem on siteground's hosting, no solution, i've disabled the update status module (Drupal 6.16)

Help please !

markpenny’s picture

markpenny CreditAttribution: markpenny commented

This seems to be a problem with Update Status. It is often blamed on low memory settings, and I can see how memory settings would be blamed, but the only time I get definite memory warnings are when I decrease the allotted memory. Otherwise, I just get The Screen.

It would be nice if we could select the modules to check during a run, or if Update Status automatically divided the modules into shifts. Not too many Drupal fans are going to limit the number of modules they install just to accommodate Update Status.

steve316’s picture

steve316 CreditAttribution: steve316 commented
Issue tags: -WSOD +WSOD - Admin Pages w/ Update Status Enabled

We too are having the same issues with the update status module. We have done everything we can think of to troubleshoot the issue.
1. We have enabled/disabled compression, cache, optimization.
2. We installed db maintenance module, and ran for all tables
3. Added code to template.php to display any errors, no erros show.
4. Looked over watchdog to see whats going on.
5. Checked with hosting company regarding memory limit and timeout settings, memory is 96mb, timeout is 45 seconds. admin pages blank out before the timeout period.

As soon as we disable update status within phpmyadmin, the error goes away, all admin pages are back, and site seems to function perfectly. No other errors in watchdog at all. As soon as we enable update status, we cant access any admin pages at all.

Here is response from host:
The root cause of the problem is the script execution limit of 10 seconds. When the update module is enabled, one of the Drupal scripts initiates a connection to their server and awaits response for the latest version which then compares with the version you are using. Since the response from them remote server is received within the execution time limit, the page timeouts and you receive a blank page.

I am afraid that on a shared hosting account the script execution limit cannot be modified because it is part of the global server limits. These limits can be modified only on our Cloud Hosting Solutions and Dedicated Solutions.

Errors we found:
Only got site to generate errors once, all reference the themes, and only one theme is active. This is from watchdog:

query: INSERT INTO system (name 35;"1";"php";"%message in %file on line %line.";"a:4:{s:6:"%error";s:12:"user warning";s:8:"%
message";s:1890:"Duplicate entry 'themes/garland/garland.info' for key 1

error varies for each default theme, however we are using a custom theme.

phperrorlog reads as follows:
[03-Jan-2011 12:17:39] PHP Warning: MySQL server has gone away
query: INSERT INTO watchdog
(uid, type, message, variables, severity, link, location, referer, hostname, timestamp)
VALUES
(1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:941126:\"MySQL server has gone away\nquery: UPDATE cache_update SET data = 'a:50:{s:10:\\"admin_menu\\";a:10:{s:5:\\"title\\";s:19:\\"Administration menu\\";s:10:\\"short_name\\";s:10:\\"admin_menu\\";s:10:\\"dc:creator\\";s:3:\\"sun\\";s:11:\\"api_version\\";s:3:\\"6.x\\";s:17:\\"recommended_major\\";s:1:\\"1\\";s:16:\\"supported_majors\\";s:3:\\"1,3\\";s:13:\\"default_major\\";s:1:\\"1\\";s:14:\\"pro in /home/precisew/public_html/includes/database.mysql.inc on line 128

steve316’s picture

steve316 CreditAttribution: steve316 commented

UPDATE !!

We have found a solution, this fixed this issues instantly

I have seen the "MySQL server
Posted by cog.rusty on April 23, 2009 at 3:43pm

I have seen the "MySQL server has gone away" error on a couple of cheap shared hosting accounts where they had set wait_timeout=15 to save connections. By the way, MySQL's default is wait_timeout=28800. 15 is a bit too drastic.

Since I had no access to MySQL's settings, I had to hack Drupal core to fix it.

In includes/database.mysql.inc, at the end of function db_connect(), under the "SET NAMES" line:
mysql_query('SET SESSION wait_timeout = 60', $connection);

In includes/database.mysqli.inc, at the end of function db_connect(), under the "SET NAMES" line:
mysqli_query($connection, 'SET SESSION wait_timeout = 60');

I guess someone with more PHP experience that me could suggest a patch to check if wait_timeout is too low and fix it in some economic way.

hass’s picture

hass CreditAttribution: hass commented

Never post personal identifiying (ip) data to the public!

rene_w’s picture

rene_w CreditAttribution: rene_w commented

Nice tip with the mysql timeout; I've tried your patch (SET SESSION wait_timeout), unfortunately it did not help in my installation, I get the same WSOD as before after ca. 10-12sec.

I asked my (shared) web hoster again if they impose a limit of 10-12sec. *anywhere* (php, mysql, ...), and they said they didn't.

Bilalx’s picture

Bilalx CreditAttribution: Bilalx commented

Try a higher value than 60. The update script take about 70s for me. Try 300 to see if it works, then lower to 90 or 120 if it is enough.

Don't forget, you have to make the change in the two files.

More info here: http://www.megacomputers.com.my/version2/content/warning-mysql-server-ha...

There is a module that seems to allow to do modify wait_timeout whithout hacking the core. I haven't tried it yet.
http://drupal.org/project/drupal_tweaks

rene_w’s picture

rene_w CreditAttribution: rene_w commented

@Bilalx: increasing the mysql limit further wouldn't help, since the script already stops after ~10sec.

However, I bugged my (shared) web hoster again and there is a workaround!

I wrote a couple of simple PHP-scripts to test memory limits, execution time, etc. outside Drupal, to find out where exactly the problem is. Turns out there is a timeout problem when running this script:

header('Content-type: text/plain');
echo date("H:m:s"), "\n";

while ($i<=9)
{
        echo "i=$i \n";
        sleep(1);
        $i++;
}

This script works fine for 10s, for 11s it is aborted and I get a WSOD, just like with Drupal. After being in denial for a couple of emails, my web hoster admitted that there is a problem and looked into it.

Their explanation is that this is a PHP bug (my server runs PHP 5.2.17 on Apache/1.3.41). They say they have a connection timeout (not execution timeout), which was apparently set to 10sec. This connection timeout should not apply when the server is still sending data to the client, like in this script, but it is aborted nevertheless; that's why they said it is a php bug (any experts care to comment?).

As a workaround, they increased the php connection timeout limit, and update_status works just like before.

Can't believe it took 1.5 years to figure this out...

patcon’s picture

patcon CreditAttribution: patcon commented

Wow. Amazing sleuthing Rene! I'm done with shared hosting now, but you'll definitely have saved someone's keister, I'm sure :)

Bilalx’s picture

Bilalx CreditAttribution: Bilalx commented

Glad you finally found a solution, even if it is a year and a half after :).

apaderno’s picture

apaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
CreditAttribution: apaderno as a volunteer commented
Issue summary: View changes
Status: Active » Closed (outdated)
Issue tags: -WSOD - Admin Pages w/ Update Status Enabled

I am closing this issue, since it's for a Drupal version no longer supported.