I look after a number of servers in my spare time 🙂 One of the guys who I help out contacted me recently with a weird Joomla issue when trying to install a particular component.
* JInstaller::install: SQL Error. DB function failed with error
number 2006
MySQL server has gone away SQL=CREATE TABLE IF NOT EXISTS
`jos_comprofiler` ( `id` int(11) NOT NULL default ‘0’, `user_id` int(11) NOT
Other modules and components would install fine, the only one failing to install was comprofiler, part of the Community Builder module for Joomla/Mambo. Other parts of the same module were also installing fine.
The full error was a bunch of MySQL inserts headed by the message above.
I had a bit of a look around and couldn’t locate any particular permission or other issues, the server was running fine with just this single module being a pain.
The Apache error log was showing line after line of errors when you tried to install the module.
PHP Notice: Only variable references should be returned by reference in /***.com/html/libraries/joomla/application/module/helper.php on line 288, referer: http://***.com/administrator/index.php
PHP Notice: Trying to get property of non-object in /***.com/html/libraries/joomla/application/module/helper.php on line 93, referer: http://***.com/administrator/index.php
Having a look through the referenced code didn’t point out anything at all and Google wasn’t much help either 🙂 So I started having a look elsewhere.
When I set the php debug errors for this domain to go to syslog I noticed in the logs that just before the error showed up each time in the logs, there was an FTP connection from 127.0.0.1
I looked into this a bit further and discovered hundreds of lines in the FTP log containing the name of the module/component that was being installed.
Breaking this down it seems to go like this, using the Joomla admin interface you select to install a module, choose a zip file from you local disk and hit install, this is uploaded to the server in the browser, straight after this we see:
Fri Jun 6 06:26:03 2008 0 127.0.0.1 563483 /***.com/html/tmp/com_comprofiler.zip b _ i r username ftp 0 * c
The web server connects to itself via FTP and uploads the zip file to a tmp folder, this is the file that you just uploaded via the web browser, huh? Next we see:
Fri Jun 6 06:26:04 2008 0 127.0.0.1 133024 /***.com/html/tmp/install_4848d87b323b5/com_comprofiler/admin.comprofiler.controller.php b _ i r username ftp 0 * c
It looks like the files have now been expanded from the zip and are being uploaded to a randomly named install directory under tmp. Next up we see more FTP action:
Fri Jun 6 06:26:19 2008 0 127.0.0.1 133024 /***.com/html/administrator/components/com_comprofiler/admin.comprofiler.controller.php b _ i r username ftp 0 * c
The exact same files that were ftp’ed into the tmp/random install directory are coming in again, this time being uploaded into the components folder.
Mean time back at the ranch, PHP has given up waiting. In /etc/php.ini this particular web server has max_execution_time = 30, so after 30 seconds of the script running it dies with an error. I assume this feeds back into the main install script which doesn’t do a great job of catching it and triggers the random errors noted above, error messages that don’t exactly lead you to the right thing 🙂
Working around this was simple enough, I uploaded the zip file to the server, unzipped it to a location inside the customer folder and pointed the Joomla admin install module at the location on disk.
The module installed successfully with no issues, but interestingly enough the admin script grabbed it from the disk location on the drive and uploaded it via FTP to the components folder.
So how many files came in over FTP in 30 seconds before the PHP execution limit was reached?
[root@server ~]# grep “06:26” /var/log/xferlog | grep -c 127.0.0.1
821
[root@server ~]#
😐 Not nice.
And how many files were FTP’ed from the server to itself when doing the install from a directory location on disk, inside the same webspace even.
[root@server ~]# grep “06:37” /var/log/xferlog | grep -c 127.0.0.1
206
[root@server ~]#
It still took 8 seconds or so to do this, but at least it was inside the PHP execution limit.
I’m no Joomla guru, today was the first time I’ve even looked at it, however it seems rather a broken and inefficient way to go about trying to get module or component files into the right spot.
You could also increase the PHP max execution time to work around this problem, I didn’t bother trying but somewhere around 60 seconds might work.
So if your Joomla module/component installs are randomly failing with error messages that are clearly wrong, you might be hitting this issue, especially for a larger module or component with a lot of files.
UPDATE: 30/06/2008
The other reason you will get this error is if your MYSQL timeout limit is too low. I’ve been using the following settings and haven’t run into any more problems installing Joomla modules.
php.ini
max_execution_time = 60
max_input_time = 60
my.cnf
wait_timeout = 60
connect_timeout = 60
Thanks for you advice. It has helped me and no doubt many others. Thanks again. Keep up the good work
Hi,
I am not sure if this helps me yet. But I like your writing style. Very clear and easy to understand — especially your descriptions leading to the cause of the problem.
Thanks for this. It worked for me. For those who don’t know, you can set the mysql variables (my.cnf) like this (if you have shell access)…
mysql> set global wait_timeout =60;
If all goes well you should see something like this
Query OK, 0 rows affected (0.00 sec)
o.k. you helped me so so you have one wish free 🙂
Thanks very much for listing this problem. I don’t know whether to throw a pan at easyspace tech support or just work around the problem like you mentioned. All I know is this has been a real pain in the ass.
Thanks again for posting
Hello,
Thanks for the advice. I have the same problem. Sadly for me I still get the error even if I upload from the directory. Any advice ?
Thanks 🙂