Hi. I'm trying to make a local testing installation of drupal-5.2 on my laptop. I'm running Ubuntu Feisty with PHP-5.2.1, lighttpd-1.4.13 and mysql server-5.0.38. The installation itself goes very smoothly until I get to the part where I need to create the very first user. I type in a username and an e-mail address, and I press the button. Then I get the following error messages:

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '<em>MySQL server has gone away\nquery: SELECT * FROM users u WHERE LOWER(name) = LOWER(&amp;#039;Apreche&amp;#039;) AND pass = &amp;#039;8e9a4090f60079e61123537e11943693&amp;#039; AND status = 1</em> in <em>/var/www/drupal/includes/database.mysqli.inc</em> on line <em>151</em>.', 2, '', 'http://localhost/drupal/index.php?q=user/register', 'http://localhost/drupal/index.php?q=user/register', '127.0.0.1', 1186069140) in /var/www/drupal/includes/database.mysqli.inc on line 151
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '<em>Cannot modify header information - headers already sent by (output started at /var/www/drupal/includes/database.mysqli.inc:151)</em> in <em>/var/www/drupal/includes/common.inc</em> on line <em>309</em>.', 2, '', 'http://localhost/drupal/index.php?q=user/register', 'http://localhost/drupal/index.php?q=user/register', '127.0.0.1', 1186069140) in /var/www/drupal/includes/database.mysqli.inc on line 151
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '<em>MySQL server has gone away\nquery: SELECT sid FROM sessions WHERE sid = &amp;#039;569e1d155d11548d3768566667e7d793&amp;#039;</em> in <em>/var/www/drupal/includes/database.mysqli.inc</em> on line <em>151</em>.', 2, '', 'http://localhost/drupal/index.php?q=user/register', 'http://localhost/drupal/index.php?q=user/register', '127.0.0.1', 1186069140) in /var/www/drupal/includes/database.mysqli.inc on line 151
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, severity, link, location, referer, hostname, timestamp) VALUES (0, 'php', '<em>MySQL server has gone away\nquery: INSERT INTO sessions (sid, uid, cache, hostname, session, timestamp) VALUES (&amp;#039;569e1d155d11548d3768566667e7d793&amp;#039;, 0, 0, &amp;#039;127.0.0.1&amp;#039;, &amp;#039;messages|a:2:{s:6:\\&amp;quot;status\\&amp;quot;;a:1:{i:0;s:443:\\&amp;quot;&amp;lt;p&amp;gt;Welcome to Drupal. You are user #1, which gives you full and immediate access. All future registrants will receive their passwords via e-mail, so please make sure your website e-mail address is set properly under the general settings on the &amp;lt;a href=\\&amp;quot;/drupal/index.php?q=admin/settings/site-information\\&amp;quot;&amp;gt;site information settings page&amp;lt;/a&amp;gt;.&amp;lt;/p&amp;gt;&amp;lt;p&amp;gt; Your password is &amp;lt;strong&am in /var/www/drupal/includes/database.mysqli.inc on line 151

I checked the mysql server to make sure that wasn't the problem. All of the tables in the database were properly created. Also, the database user privileges and authentication are setup correctly. The mysql server logs are free of any errors, and the server did not crash or fail in any way. I searched for solutions on Google, but the few I tried didn't help at all. What should I do?

Comments

Hi!

I got the same "MySQL server has gone away query" Filling up the page when accessing different nodes or trying to edit or save changes. What to do What to do?

Hi:
Same problem.
I checked the mysql pages on "packet too large" and "gone away". But I cannot see that the sql that is issued would really go beyond size limitations at this point. I also checked privileges in the database, and mysql config.
The mysql instance I have been running has not had any issues, been running stable with a variety of applications. Also other php applications under lighttpd.

My environment is:
Drupal 5.2 (and I tried 5.1 as well)
PHP5.2
mysql 5.0.38
lighttpd 1.4.13.

Any help is appreciated.
Thomas

Thomas

--
Common sense is uncommon
(Tom Gilb, Principles of Software Engineering Management)

The problem is the same to me. here is my env:

Debian lenny
PHP Version 5.2.3-1+b1
lighttpd-1.4.16 (ssl)
Mysql 5.0.45
Drupal 5.2

I just tested this again, and the issue still exists. From posts here I am almost 100% positive that this is a bug when you combine lighttpd, Drupal 5+, and PHP 5. Drupal is most definitely the problem because other PHP applications work in this environment without incident. This is particulary a problem for people running Drupal on systems such as Ubuntu Feisty because the default on those systems is to use this combination of software on which Drupal will not work. I think this is a pretty serious bug considering the fact that despite much trying, I can't figure it out. I'm a PHP programmer btw, I just have little to no Drupal experience.

GeekNights, the late-night podcast for geeks.

I know little about Linux, php, mysql, drupal, lighttpd, apache, etc. Since I can't google a solution, I finally back to Apache2, with apc installed.

Using LAMP is so easy to drive a drupal site.

I think I have this fixed. I got Drupal running on my laptop now with the same setup, but I'm not sure exactly what fixed it. It might have been an update to Ubuntu, I haven't checked. It also might have been because I did a chmod -R root:www-data /var/www/drupal. When you unzip drupal all the files are owned by some unspecified user. I don't know how this could possibly cause or solve this problem, or even if it did, but it's working now. That's all that matters.

GeekNights, the late-night podcast for geeks.

I had tried chown -R www-data:www-data /var/www/drupal before, but no luck.

but my os is Debian lenny.

I have identical copies of a site running on two servers, one running Ubuntu Dapper and the other running Ubuntu Feisty. The Dapper server (running lighttpd 1.4.11-3ubuntu3.5) exhibits the problem when running cron.php (update_status seems to trigger it), the Feisty server (running 1.4.13-9ubuntu4.2) doesn't.

There's a ticket with a patch related to this over at the lighttpd project site: http://trac.lighttpd.net/trac/ticket/518

I suppose this fix isn't rolled into lighttpd 1.4.11-3ubuntu3.5.

Henrik Sjökvist // Kollegorna

I am running php5, mysqlserver5 and Drupal 5.2. I have no db issues when accessing my site remotely (ie. http://myaddress.com), but when I try to debug locally (http://localhost/) I get the MySql Server has gone away on some pages. This is a major problem on pages where I am using JSON transactions because the extra error message ruins my json format and makes it impossible to debug these links locally. Have there been any further insights as to what causes this error?

maybe this is what ur looking for

http://drupal.org/node/186384

hope it helps

According to error messages you must just increase size of "referer" field in {watchdog} table:

ALTER TABLE `watchdog` CHANGE `referer` `referer` VARCHAR( 420 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL

And that's all.

I have 2 sites running on Lighttpd/Mysql 5/PHP 5 and once I increased the referer field it fixed my error WITHOUT disabling the update status module. From what it was trying to insert in the table, it was maxing out the field.

Any idea how to fix this if you don't have shell access on your account? I too am getting this error (Drupal 6.8, PHP 4.4.8, MySQL 5.0.51a). I only have cpanel and ftp access on my webhosting, so I can't access the my.cnf file to try the fixes indicated above.

The way out for this labyrinth for me has been disabling the (helpful btw) Update Status 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.
By the way, I'm quite happy with the technical support of my hosting service allowing that fine tuning.

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 Disable the module

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

Thanks, I will try this, though the update status module is not something I'm really happy to disable.

TKS, disabling update status works for me.

Disabling update status works here too (6.19) - although the irony is that without it we won't know when the problem's fixed :-)

When I set up my first site in a drupal 6.12 on a hosted server all worked fine. I installed several modules - no problem.

After a couple of weeks a wanted to install an additional site. First I ran into an timeout problem:
"Maximum exectution time of 30 seconds..."
I could fix it by adding
"ini_set('max_execution_time', 0);"
to settings.php. After that an other problem came up:
"MYSQL server has gone away..."

The reason for both problems was the update status module which seems to be enabled by default for a fresh installation.
During tests and especially when I didn't have internet access it takes much time - either for waiting for timeouts or for checking the status.

I could solve the problem by renaming the current sites/all directory to sites/all.work and creating an empty sites/all directory. After that I ran the installation of the new site, renamed sites/all to sites/all.clean and sites/all.work to sites/all afterwards.

That's it! Thanks a lot ;-)

www.calbasi.net
Ps: If you can not understand me, it's my poor English skills fault :-p

I confirm that it was worked around here by disabling the update module. It's a useful module, though. Don't think it's a clean fix.

I'm on a shared host, and my problem seemed to be that in MySQL, wait_timeout was set to 5 (the default is 28,800).

I fixed it by installing Drupal Tweaks, enabling the Database Tweaks module, and bumping Default Wait_Timeout Value to 10.

That said, I'll probably leave the Update module disabled and only turn it on when I'm doing maintenance, since I suspect it's a bit of a performance drag.

worked for me.

Have a nice day.

Leapfrog Web Solutions
http://leapfrog.cl

Thx you so much it work for me too but Update Module is the core & useful module i'm happy if there is another way to stop this problem.

Hi thanks, disabling the update status solved my problem of geting warning "drupal user warning: MySQL server has gone away query:"

Thanks once again

Hi thanks, disabling the update status solved my problem of geting warning "drupal user warning: MySQL server has gone away query:"

Thanks once again

I have the same probleme on a multisites installation.

When I disable update status module, I don't have this problem anymore but I enabled this module (and all other modules) on a non-used site on this installation to get warned when ther is updates, but when I call the cron on this site I get a loop of :

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES ( ....

So how can I do to get update notifications now ?

Edit: if I disable the database loging I no more have this prob, but cron still don't work and I can't see new updates

i too am having this issue but i disable the update status module and all went so is it something in that module that connects to drupal.org to get module status updates that my server doesnt like? sorry if someone has solved this :D

love Drupal! what more can I say?

Hi @all,

i solved the problem.

I use an local apache server with mysql (xampp).
In my my.cnf (under windows my.ini) file i insert following text.

wait_timeout = 120

edit:
Sorry, after reboot is the issue again

I use apache and changed it into my.cnf and no problem after that.

wait_timeout = 60

Just reboot mysql service is enought

I recently had this message when playing with image uploads.

At first the uploading was working great, then I got "Fatal error: Allowed memory size of 33554432 bytes exhausted"

So I increased the memory_limit in the php.ini file.

After that I got the " Warning: MySQL server has gone away query:" message that filled up the page.

I could still upload images fine in individual nodes but not through content management so I deleted the image module and reinstalled a new one and works fine again no more message.

So seems like mine the module got corrupted.

I had this same problem today. In my case, my Drupal-cron-script was shepherding a long ffmpeg conversion (about two minutes total elapsed time in unix nice mode).

After some detective work I found that the problem is that the default mysql variable wait_timeout is set to 10 seconds... so my MySQL server had dropped the database connection and when my process was done it could not save its results back into the database.

The MySQL manual on Server System Variables ( http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html ) pointed out that the initial global default value of wait_timeout is set in the my.cnf file. Unfortunately my website is on a shared host machine and so I do not have access to the my.cnf file for my database server.

Fortunately, the same section stated that the value of wait_timeout for my current session could be (re)set in my Drupal-cron-script using the MySQL command: SET wait_timeout=1000;

This worked for me.

NOTE however this trick should only be used as a last resort AND the timeout value should be kept as small as possible.... otherwise you will end up with too many database connections staying open for too long... seriously impacting overall performance for your website.

Ok. here's what I did that wouldn't seem to work, but totally did and I want you guys to try and tell me if it works for you.

TO THE POINT:

Run mysql and regrant the permissions to the database for the user speicified in your drupal installation in /sites/default/settings.php.

ex.

mysql> GRANT INSERT ON development_db.watchdog TO 'test'@'localhost' IDENTIFIED BY 'secrect_password_you_ll_never_guess';
mysql> FLUSH PRIVILEGES;

LONG WINDED VERSION:

Thought it might be that tables permissions since everyone was getting the exact same errors on the exact same table, and it worked.

I'm going to investigate this on the mysql page an in the dump file for my db to see what might cause mysql to loose permissions, but if you guys get the same results then we're getting closer to solving this issue. I hope someone sweet at MySQL reads this.

Drees' is my homeboi!

Didn't work for me, I'm afraid. :(

This worked for me! I've got my dev environment working on an Aegir server. Somehow when I migrated my site within Aegir to a new platform this error started showing up. I tried all of the other solutions such as max_allowed_packet = 100M, but none of those solutions work. Your database GRANT solution did work, very cool, thanks for the info!

--Tony

如果是第一次安装就这样那么可以通读下面全文

全文http://blog.renren.com/blog/232249667/494873889

方法总结:

1.配置settings.php

在里面增加ini_set('memory_limit', '32M');

2.安装时关闭update automatic

3.修改system.modules模块

function system_check_http_request() {
// Try to get the content of the front page via drupal_http_request().
$result = drupal_http_request(url('http://www.baidu.com', array('absolute' => TRUE)));
其实是指向了百度,之前讲指向我的空间是希望读者踩踩我的空间

4.在variable表中增加一条记录

name="drupal_http_request_fails"

"value= b:0;"

5.cron manually

6.去掉ini_set('memory_limit', '32M');

7.啤酒庆祝

不是不懂英文,而是支持中文!嘿嘿

I had this problem. I wasn't able to update the .ini file as I only have FTP access to my shared hosting. A workaround for the time-being is to disable Update Module. If you have cPanel access to your host follow the steps here (http://drupal.org/node/157632) and everything should be fine.

hi
i put @ in back of trigger_error(check_plain(mysqli_error($active_db) ."\nquery: ". $query), E_USER_WARNING);

and warning was disappear

I get this error every time I try to add any content. The error occurs as soon as I select Content management > Create content > content type.
Here are the fixes I applied:

  1. removed module option Update status
  2. xampp/php.ini:
    memory_limit = 256M
  3. xampp/mysql/my.ini:
    wait_timeout = 120
    max_allowed_packet = 200M
  4. xampp/htdocs/drupal_commons/includes/database.mysql.inc
    end of function db_connect($url) added:
    mysql_query('SET SESSION wait_timeout = 120', $connection);
  5. xampp/htdocs/drupal_commons/includes/database.mysqli.inc
    end of function db_connect($url) added:
    mysql_query('SET SESSION wait_timeout = 120', $connection);

I tried copy/pasting one of the queries into phpmyAdmin, I got a message saying the query ran OK

1 row(s) inserted.
Inserted row id: 31543 ( Query took 0.0383 sec )

this one of the errors I have - I have several pages, they all look similar.:

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:259:"MySQL server has gone away\nquery: UPDATE cache_menu SET data = &#039;links:navigation:tree-data:54da1c74bce270d4ef16dc5a14a72eb2&#039;, created = 1308148249, expire = 0, headers = &#039;&#039;, serialized = 0 WHERE cid = &#039;links:navigation:all-cid:0&#039;";s:5:"%file";s:49:"C:\\xampp\\htdocs\\drupal_commons\\includes\\cache.inc";s:5:"%line";i:108;}', 3, '', 'http://lo

Francis

I unchecked the module named Database logging
I also had an error in the content type i was trying to create, which led me to believe it was the View that was at fault - by changing the widget type of one of the fields, it removed the error

Francis

This may help you! As I saw this problem coming up still.
Check your mysqlconfig. If yours is mysqli and you have put mysql in place of mysqli in settings.php where you set your database connection.

Check and change. This worked for me.

Jeet

ERROR:

Warning: MySQL server has gone away query: UPDATE cache SET data = 'a:524:{s:11:\"admin_theme\";s:7:\"garland\";s:22:\"aef_allowed_formatters\";a:4:{s:18:\"element_multimedia\";a:32:{s:19:\"field_em_show_title\";a:2:{s:24:\"user_formatter_selection\";s:4:\"none\";s:18:\"allowed_formatters\";a:5:{i:0;i:0;s:7:\"default\";b:0;s:5:\"plain\";b:0;s:7:\"trimmed\";b:0;s:6:\"hidden\";b:0;}}s:29:\"field_em_video_node_reference\";a:2:{s:2
4:\"user_formatter_selection\";s:4:\"none\";s:18:\"allowed_formatters\";a:49:{i:0;i:0;s:7:\"default\";b:0;s:5:\"plain\";b:0;s:4:\"full\";b:0;s:6:\"teaser\";b:0;s:23:\"aef_ct_article_teaser_1\";b:0;s:23:\"aef_ct_article_teaser_2\";b:0;s:23:\"aef_ct_article_teaser_3\";b:0;s:30:\"aef_ct_article_vertical_teaser\";b:0;s:33:\"aef_ct_article_teaser_s in
/var/www/html/drupal/includes/database.mysql.inc on line 135 Warning: MySQL server has gone
away query: SELECT name, filename, throttle FROM system WHERE type = 'module' AND status =
1 AND bootstrap = 1 ORDER BY weight ASC, filename ASC in /var/www/html/drupal/includes/database.mysql.inc on line 135 Warning: MySQL server has gone away query: SELECT * FROM languages ORDER BY weight ASC, name ASC in /var/www/html/drupal/includes/database.mysql.inc on line 135 Notice: Undefined index:
language in /var/www/html/drupal/includes/bootstrap.inc on line 1281 Warning: Invalid argument supplied for foreach() in /var/www/html/drupal/includes/bootstrap.inc on line 1281 Notice: Undefined offset: 1 in /var/www/html/drupal/includes/language.inc on line 18 Warning: MySQL server has gone away query: SELECT COUNT(pid) FROM url_alias in /var/www/html/drupal/includes/database.mysql.inc on line 135 Fatal error: Call to undefined
function filter_xss() in /var/www/html/drupal/includes/common.inc on line 655 Warning: MySQL server has gone away query: UPDATE sessions SET uid = 0, cache = 0, hostname = 'IP..', session = '', timestamp = 1323417473 WHERE sid = 'mstchoipo1co9rp2k6f5mpgfc2' in /var/www/html/drupal/includes/database.mysql.inc on line 135

Solved with max_allowed_packet = 64M in etc/my.cnf
Thanks to Dan of BMEME team