Akeeba Backup for Joomla!

Thursday, 05 September 2013 01:45 CDT

artbeat

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (Chapter 3. Using the Akeeba Backup component)? Yes
Joomla! version: (2.5.7 through to 2.5.14)
PHP version: (5.3.18)
MySQL version: (unknown)
Host: (Rackservers.com.au)
Akeeba Backup version: (3.7.7 through to 3.7.10)

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

Running Akeeba backup via a cPanel Crob Job has worked fine for several sites until recently. Now, when run via a cron job it throws the following error in "error_log":

PHP Fatal error: Uncaught exception 'JDatabaseException' with message 'Unable to connect to the Database: Could not connect to MySQL.' in /home/thebrand/public_html/libraries/joomla/database/database.php:346

There are no errors in the Akeeba log - or anything at all in fact since I reinstalled the site.

This is now happening across all my sites that are hosted in the same Rackservers reseller account. I also have an identical Rackervers reseller account setup for another business where the backups are still working fine. Hosts don't seem to think the issue is their end.

Running a backup manually still works fine.

I can't isolate any incident that would have caused them to stop working - I've been updating Joomla and JCE editor recently, but neither seem to exactly correspond to when the back ups stopped working.

Permissions seem fine, as does the database setup in configuration.php. Everything else in the site still seems to work fine. I've reinstalled past backups but the cron job still fails.

Thanks for any help you can offer...

Thursday, 05 September 2013 02:36 CDT

nicholas

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

I can think of two issues (you have accidentally added an extra database without a proper db definition or you are using localhost instead of 127.0.0.1 in your Global Configuration to connect to your db). Without a log file I can't possibly know which one it is.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Sunday, 08 September 2013 22:49 CDT

artbeat

Hi Nicholas

I've checked and there is no extra database and I'm using localhost to connect to the DB. The problem is across about 6 sites and just happened recently.

I've attached the Akeeba log from a different site that isn't working (since the original site I referenced above didn't have anything in the Akeeba Log).

Monday, 09 September 2013 00:42 CDT

nicholas

Thank you for the log file. You do not have the problem you are purporting to be having. The only problem you have on that site is failure to upload to Dropbox (the backup itself has completed successfully):

DEBUG   |130901 00:05:29|Loading post-processing engine object (dropbox)
INFO    |130901 00:05:29|Continuing post processing file /home/fitnessr/public_html/administrator/components/com_akeeba/backup/site-www.fitnessrevolution.com.au-20130901-000006.jpa
WARNING |130901 00:07:23|Failed to process file /home/fitnessr/public_html/administrator/components/com_akeeba/backup/site-www.fitnessrevolution.com.au-20130901-000006.jpa
WARNING |130901 00:07:23|Error received from the post-processing engine:
WARNING |130901 00:07:23|Dropbox was unable to complete this action because of a storage quota limit. (Status Code: 507)
DEBUG   |130901 00:07:23|Not removing processed file /home/fitnessr/public_html/administrator/components/com_akeeba/backup/site-www.fitnessrevolution.com.au-20130901-000006.jpa

Why is that? Because you run out of space in your Dropbox account. Therefore there is nothing for me to help you with.

FYI, these lines which made you think you have a problem:

WARNING |130901 00:07:23|PHP WARNING on line 141 in file /home/fitnessr/public_html/libraries/joomla/database/database/mysqli.php:
WARNING |130901 00:07:23|mysqli_close(): Couldn't fetch mysqli
WARNING |130901 00:07:23|PHP WARNING on line 190 in file /home/fitnessr/public_html/libraries/joomla/database/database/mysqli.php:
WARNING |130901 00:07:23|mysqli_ping(): Couldn't fetch mysqli
DEBUG   |130901 00:07:23|Closing SQL dump file.

are perfectly normal. It's a known bug in Joomla!'s MySQLi driver implementation which will be fixed in Joomla! 3.2. It doesn't cause any problem with Akeeba Backup. It simply means that Joomla!'s MySQLi driver is trying to close the MySQLi connection twice, making PHP complain that there is no connection to close.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 September 2013 01:20 CDT

artbeat

Hi.

I am aware my dropbox was full at one point. But that is not the issue I am having now. I emptied it out and I can still run a backup manually that uploads to dropbox fine. It's just when running it via a cron job that I have problems.

As mentioned, to troubleshoot the issue I reinstalled a much older backup on another site and reinstalled Akeeba, but still get the problem. There is no Akeeba error log for this site, just the generic server log that I first attached, which says it cannot connect to the database.

The email notification I get when running the cron job only says:

Akeeba Backup CLI 3.7.7 (2013-05-11)
Copyright (C) 2010-2013 Nicholas K. Dionysopoulos
-------------------------------------------------------------------------------
Akeeba Backup is Free Software, distributed under the terms of the GNU General
Public License version 3 or, at your option, any later version.
This program comes with ABSOLUTELY NO WARRANTY as per sections 15 & 16 of the
license. See http://www.gnu.org/licenses/gpl-3.0.html for details.
-------------------------------------------------------------------------------
You are using PHP 5.3.18 (cli)

Starting a new backup with the following parameters:
Profile ID 1
Description "Command-line backup"

Current memory usage: 2.11 Mb

Unsetting time limit restrictions.

Site paths determined by this script:
JPATH_BASE : /home/thebrand/public_html/cli/../
JPATH_ADMINISTRATOR : /home/thebrand/public_html/cli/..//administrator

Monday, 09 September 2013 01:38 CDT

nicholas

In this case, this site has a completely different issue than the site whose log you sent me. Please contact your host at once and ask them to allow CLI applications to connect to their MySQL database. Most likely they've screwed up the permissions of MySQL's named pipe. Alternatively, edit your configuration.php and change 'localhost' with '127.0.0.1'. Before you think I am insane, PHP treats these two values differently:
- 'localhost' means that PHP will try using a named pipe to connect to the database. This is usually faster but is prone to breakage due to permissions (what happens in your case, as the CLI and web versions of PHP run under different system users)
- '127.0.0.1' means that PHP will try using TCP/IP to connect to the database. Unless your host has disabled that MySQL feature, this is the most resilient connection method.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Monday, 09 September 2013 21:37 CDT

artbeat

Thanks Nicholas.

Using 127.0.0.1 worked. Unfortunately the hosts think locahost should work, their response being:

localhost should work.

root@lincpan100 [/root]# ping localhost

PING localhost (127.0.0.1) 56(84) bytes of data.

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.143 ms

64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.175 ms

As it is pingable. I would say more than likely maybe there is something wrong with the db. Or maybe its just the wrong settings for the db in the file they described

I can live with the 127.0.0.1 if I have to, but localhost would be better across all my sites.

I don't think the DB is the issue (from my end at least) since the problem has occured across multiple sites - any chance it could be settings in the configuration file. Again I don't think so as I have the same setup on several other sites (on another account with the same host) that still work.

Any other ideas you have are appreciated otherwise I'll give up and go with the 127.0.0.1 solution.

p.s. can I change this to a private ticket so I can upload my configuration file?

Tuesday, 10 September 2013 01:07 CDT

nicholas

My advice? RUN AWAY! The host is clueless! And let me explain why.

Since you were using 'localhost' for the database server name, PHP was trying to access MySQL through named pipes. Named pipes do not go through the network; they are something like files on the server that instead of pushing data to and from the disk they push data to and from a programme running on the server. That's the overall idea. Just like files, named pipes have the notion of ownership and permissions. If your host screws up, the PHP CLI process running under your user account can't access MySQL's named pipe. That was your problem.

I told you to use '127.0.0.1'. This tells PHP "do not use named pipes; use TCP/IP networking instead". This means that PHP now tries to connect to MySQL through TCP port 3306 which is of course open.

So what did your host do with the PING? They tried to establish that TCP/IP networking works. Which we already know that works, as my solution worked for you.

Your host has no idea how MySQL works, does not understand fundamental concepts of their server's operating system (named pipes, ownership, permissions) and has displayed incompetence beyond words. If I had hired the person who replied that stupid crap to you I would fire him on the spot and KICK HIM OUT of the office for being an dangerously incompetent moron.

So, please, fire your host and find a host that actually understands how their servers work...

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 10 September 2013 02:05 CDT

artbeat

Thanks Nicholas - good advice

I appreciate all your help on this...

Tuesday, 10 September 2013 04:38 CDT

nicholas

You're welcome!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support