Hi,
I updated my site from 5.12 to 5.14. That went well.
But when I wanted to go into admin screens I got a screen full og MYSQL GONE AWAY warnings and than MYSQL LOCK TABLE and no update of cache. So I couldn't work with the site anymore.

The warnings I got was a couple of screens full of:

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '<em>MySQL server has gone away\nquery: LOCK TABLES cache WRITE</em> in <em>/public_html/includes/database.mysql.inc</em> on line <em>174</em>.', 2, '', 'admin', 'http://www.example.nl/', 'ip-number', 1230632353) in /public_html/includes/database.mysql.inc on line 174

Only after disabling update-status module I got my site working again!
Thanks a lot for going into this!

Greetings,
Martijn

Comments

edvanleeuwen’s picture

edvanleeuwen
Primary language Dutch
Location Waalwijk
CreditAttribution: edvanleeuwen commented

Ok, this is the same I suspected: http://drupal.org/node/222073#comment-1179229

webernet’s picture

webernet CreditAttribution: webernet commented
Status: Active » Closed (won't fix)

"MySQL server has gone away" has nothing to do with the update_status module.

Summit’s picture

Summit CreditAttribution: Summit commented

How is it then, that when I disable the update_status module, the errors are gone and the site respons normal.
Enabling the update_status module, I got after 2-3 minutes waiting a whole screen full of MYSQL server has gone away errors.
There must be a connection then, may be the update_status module is asking for to much resources?
May be finetuning needed?

Can I set this than to actice again, because I find it not normal that with enabling the update_status module I got all these warnings and a non-functional site, and with disabling I got a working site, but no update information, like security fixes?

Thanks a lot in advance for again going into this.
Greetings,
Martijn

Summit’s picture

Summit CreditAttribution: Summit commented
Status: Closed (won't fix) » Closed (duplicate)

Duplicate of http://drupal.org/node/222073 and see http://drupal.org/node/186384 also.
Greetings, Martijn

espirates’s picture

espirates CreditAttribution: espirates commented

I was told by my host that these mysql away warnings has everything to do with the module and/or the manner in which Drupal uses it is and also resource intensive and not secure. I don't know much about any of that but since the messages do go away after you disable the module, chances are it's the module or Drupal. Tuning Mysql doesn't do anything. D6 the warnings keep appearing as long as the update module is enabled.

ngaur’s picture

ngaur CreditAttribution: ngaur commented

My problems also went away after disabling the updates module, though I'm using D6

ngaur’s picture

ngaur CreditAttribution: ngaur commented

I don't have a clear understanding of what the mysql query limit is that is being over-run, but the updates module clearly is a big enough contributor to the problem that it's presence or not is likely to make the difference.

Given an otherwise unusable site, (varying between the 'Mysql has gone away' symptoms and the 'White Screen of Death' symptoms, depending on which page is viewed), I've been able to get the site functioning by removing the updates directory from the core modules folder.

Is someone able to clarify what the limit that is being overrun is? There's reports that changing mysql's max_packet_size variable helps many people. Why is the update packet causing such a large packet to be generated?

Is it possible to lessen the impact on the mysql server from the updates module?

ngaur’s picture

ngaur CreditAttribution: ngaur commented
Status: Closed (duplicate) » Needs work

I'm removing the 'duplicate' status of this issue, at least for discussion purposes.

This issue does not look to me to match the symptoms of bug #222073: Update Status causing Drupal to run very slowly

[#186384] does appear to match the symptoms, but multiple causes are possible. At least some of those are apparently specific to the way the updates module is implemented. (Correct me if I'm wrong on that, but some explanation would be appreciated). It seems to me to make sense to address the issue as related to the updates module rather than being a general post installation support issue.

People have identified problems with exceeding mysql's max_packet_size. Why is the updates module generating such a big packet? Is it possible to store the data differently such that this issue goes away?

While there are no doubt other possible causes of large packets, it seems clear that the updates module is a common cause of this symptom.

hass’s picture

hass CreditAttribution: hass commented
Status: Needs work » Closed (duplicate)

Solution: http://drupal.org/node/186384#comment-284542

espirates’s picture

espirates CreditAttribution: espirates commented

That's not really a solution, drupal is the problem not mysql.

hass’s picture

hass CreditAttribution: hass commented

http://drupal.org/requirements

Note: When using Drupal 5.x or later, particularly with contributed modules, it may be necessary to set the system variable max_allowed_packet to at least 16M. Some inexpensive hosting plans set this value too low (the MySQL default is only 1M). In that case, you may need to choose a better hosting plan. A value of 1M may be sufficient for 5.x.

[mysqld]
max_allowed_packet=16M

Sum up - Your server setting does not fulfil the Drupal requirements. Fix your broken server settings, please.