Support

Akeeba Backup for Joomla!

#8528 Native CRON backup timeout

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Wednesday, 21 July 2010 06:41 CDT

rbradbury
Have set up CRON job using following script
/usr/bin/php5 /home/sites//public_html/administrator/components/com_akeeba/backup.php
It has run successfully backing up to S3; and it usually runs OK when manually tested from Control Panel.
Problem is that recent automated (timed) backups get as far as creating 9 or 10 30MB backup files, then a timeout is flagged in the Akeeba log.
Checking through other posts suggests the CRON script may be using cgi, (INFO line in log), but I'm using php5 path confirmed by web host.
Would appreciate your help!
Thanks
Bob##log##

dlb
Bob,

We should be able to fix this by adjusting the magic numbers. I normally pass these to Nicholas because I'm just a junior wizard. :) On the Akeeba Configuration screen, set the minimum execution time to 1 second, the execution time bias to 50% and reduce the maximum execution time. Generally speaking, moving these controls to the left increases the time your backup takes, but decreases the chance for a timeout. Moving them to the right speeds up the backup but increases the chance for a timeout. There is no one right answer. If you can't find a combination that doesn't time out, let me know and we'll get Nicholas on it. :)


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

rbradbury
Thanks for the quick reply Dale

Have just adjusted as you suggest and manually triggered the CRON job successfully. Let's see what tomorrow's automated run brings! :D

Regards

Bob

rbradbury
Looks as though the job timed out again. Log attached
##log##
(Has just worked fine with manual test of CRON script) ##log success##

Here's an extract from my webhost helpdesk which suggests they have run the script OK from my account's command line without an error being generated....
#

Hi Bob,

We do have scripts to kill processes automatically if they cause problems on the servers, though if one of these had stopped your cron job you would have been sent an email about it. The script itself runs fine when I run it from the command line on your account so it may be that it is timing out when you call it via the cron as it did run for quite a long period when I ran it manually.

Can you shorten the script at all?

Best Wishes,
Andrew Mchardy
Heart Internet

Heart Telecom: 24Mb broadband for home & small businesses

#

UpdatedAt 15:30 20/07/2010, you changed the ticket status to OPEN and wrote:

Hi Andrew - thanks for your reply.

Unfortunately the script cannot be shortened as such - it has a fairly large job to do in performing a full backup and then compressing it for download. Akeeba recognise that server timeouts can be an issue, so provide various settings that can be tweaked to limit instruction time etc. In conjunction with their input, these have been backed off without seemingly making any difference. I guess if the server isn't killing off the job, the problem lies elsewhere.

Having checked the backup directory [ /public_html/administrator/components/com_akeeba/backups ], I can see that your manual test did not in fact fully complete - it too stopped 4x30MB files short of the full backup. This is at least a consistent error, even if not yet understood! The final stage of the backup is to copy the complete set of backup files to Amazon S3 cloud storage, then the webserver files are deleted.

Bob

#

UpdatedAt 15:39 20/07/2010, Andrew Mchardy changed the ticket status to CLOSE-PENDING and wrote:

Hi Bob,

If the script is failing at the same point even when called manually on the server with no restrictions it would suggest there is a problem somewhere as no error were given when I ran it. I would suggest contating the script writer to see if they can provide you with a copy that can output more details as to what is happening so we can try to locate exactly where it is failing.

dlb
Bob,

I'll flag this for Nicholas to see if he can give you some better magic numbers.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

rbradbury
Thanks Dale
A bit more info from my host's CRON error message today (didn't appear in yesterday's). The backup got as far as 10 out of the expected 13 x 30MB split archives
PHP Fatal error: Maximum execution time of 30 seconds exceeded in /home/sites/iloc.co.uk/public_html/administrator/components/com_akeeba/akeeba/factory.php on line 60
Again, it was possible to run the command manually through to completion via CPanel's test button.

Bob

nicholas
Akeeba Staff
Manager
You are indeed using the CGI binary which has an inflexible time limit of 30 seconds. This can not be used for CRON backup. There are the following workarounds:

1. Convince your host to give you the path to the PHP5 CLI (command line interface) binary. They should know if and where they have it on their server. The CLI binary does not have a time limit and the full backup can run without timing out.

2. Try using the altbackup.php script. It uses the front-end backup mode of Akeeba Backup. The rationale is that the time spent waiting for the front-end backup page load doesn't usually count towards the script execution time, so the backup can take longer "real clock time" than the execution time limit set in the PHP CGI binary. This was found to be perfectly working on most cPanel hosts.

3. If none of these workarounds are possible, you can use the front-end backup mode in conjunction with wget or curl, as described in our documentation.

4. Even if this is not an option, you can still use Akeeba Remote Control to schedule the backup to be launched from your local PC. This is a half-baked solution, but since the responsibility of running the backup lies with the local machine, the possibility of a timeout is eliminated. On the flip side, you do need to have a PC up and running (and conencted to the Internet) to run the backup.

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!

rbradbury
Nicholas - thanks for your detailed reply. Have now obtained the correct path to the PHP5 CLI from my host (Heart Internet) - for info it's /usr/bin/php5-cli

Everything now works fine from the scheduled CRON job - have also restored original magic numbers and successfully backed up a 480MB site - and also copied it to S3.

Not only is your app is brilliant - the support is first class too!

Bob

nicholas
Akeeba Staff
Manager
Thank you for your kind words! We always try to provide the best level of support possible and, most certainly, always explain the rationale behind our suggestions. I am glad you sorted it out with your host :)

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 Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!