Support

Based on your log I see that the backup process started around 12/12/29 07:00:07 and the last log entry is 12/12/29 07:02:47. Do you notice something? That's two minutes and 40 seconds (160 seconds). This is consistent with the timeout limit set to CRON jobs by most hosts. Please ask your host to lift the time limit from your CRON jobs. The backup needs about 14 minutes to complete. With a CRON time limit less than 3 minutes there's no way you can run a backup.

The log files are gobbldy gook to me so I hope you can see clues in there. The backup file that I am trying to complete is only 39MB. It still works fine doing a backend backup.

Knowing that the backup does complete from the backend tells me that we are not hitting a file size limit. That's good to know because we can cross out one potential issue.

The fact that the backup stops exactly at 3 minutes (180 seconds) is disconcerning. I know what your host said, but whenever I've seen that before it's always been a CRON time limit on the host. Here's a way to figure out if it's the database usage that's killing the script or a time limit. Set the backup type to "Files only" and run it again through CRON. If the first log timestamp up to the last timestamp before the final "Kettenrad :: Attempting to load from database (cli)" message is exactly 3 minutes then your host does have a CRON job maximum execution time. Actually, please do that and send me the log file. I would like to see what a files only backup reads.

I did notice that the log is reporting the wrong version on PHP. It states that the site is running 5.4.9 but in fact I am using 1H software to control my PHP versions and this site is running PHP 5.2.17 I'm not sure if this is a factor.

Regarding your PHP version it's controled by the binary of PHP that you are using in your CRON job. Please note that the version of PHP you use in the CRON job may be completely different than the one you use on your server. The explanation is very technical but it can be simplified by saying that the PHP executable file used by the web server and the CRON job are completely different and can belong to different PHP versions. For example, on my machine, I am only using PHP 5.3.14 in CLI mode (the same thing used in CRON), but on the web server I can freely switch between PHP 5.2.17, 5.3.14 and 5.4.4. Which one I use on the web server doesn't have anything to do with the one I use on the CLI. In any case, Akeeba Backup is tested against PHP 5.2, 5.3 and 5.4 and does run without a problem. The PHP version is not an issue. You also have ample memory and time limits. The backup termination doesn't come from PHP.

I scanned through the log file and noticed quite alot of references to the component 'stalytics'. Do you think that this could be the problem?

That would be the last thing to cross my mind. It would mean that accessing those tables takes too much CPU power and causes the server to kill the backup. According to your host (and from what I can guess looking at the timing data in the log) this is not the case. Another case would be hitting a file size limit due to tons of data in those tables. The fact that the backend backup does complete and is relatively small (39Mb in total) tells me that this is probably not a problem. So, my educated guess is that those references are not directly realted to the issue you are experiencing.

That backup only took 1 minute and 27 seconds (87 seconds in total), which is less than the 160 or 180 seconds ceiling we were seeing in the failed backups. It's also 34Mb. This tells us a few things:

• The file size is unrelated to the issue, as I expected. If there was a maximum backup file size issue this backup would have failed as well.
• As long as your backup takes less than 160 seconds it completes. This is consistent with what I was saying all along, that the CRON daemon is set up to kill CRON jobs after a little less than 3 minutes, despite what your host says. There's also a small possibility that we're hitting a CPU usage limit, even though your host told us that most likely we don't.

So, there's one more test you can do to be perfectly sure. You can set up a CRON job using WebCron.org to backup your full site (files and database). In order to do that, first set the backup type to Full Site Backup, then use the Scheduling Information page of Akeeba Backup to set up a scheduled backup on WebCron.org. If that completes we can rule out the CPU usage limit and be absolutely sure that the server's CRON daemon enforces a time limit on the CRON jobs.

I have some more information in case this helps your host debugging the issue. All UNIX derivative operating systems, including Linux and Mac OS X, can set user limits. These can be viewed by typing ulimit in the command line. One of those limits is the CPU time which can be shown with the ulimit -t command. If that limit is around 150-180 seconds it would explain why the CRON job never finishes, especially if it's a hard limit (enforced by the Linux kernel).

It is possible to set per-user limits. This depends on the actual operating system and distribution used. For example, in Ubuntu Server (and I believe RHEL and CentOS based on my brief Google search on the issue) we can edit the /etc/security/limits.conf file and set per-user or per-group limits. Further info: http://linux.die.net/man/5/limits.conf

For what is worth, I used to have this issue when I started hosting with Rochen. They were kind enough to add my user to a different group with very high usage limits so that my backup and site maintenance CRON jobs would complete without being killed.

Actually, this is a positive result. The log tells me that the backup run for 8 minutes and ten seconds (490 seconds). Try running a webcron.org backup with a time limit of 1800 seconds (that's half an hour). Also make sure that the backup won't start more frequently than once per hour. IMPORTANT: Do not use WebCron.org's test button, it won't work. Schedule the backup to start, say, 5 minutes from now and run once a day with a time limit of 1800 seconds.

OK, that's what I expected to happen :) I'm pretty sure that there is a user limit on the maximum CPU time. AFAIK it's the default limit of three minutes that comes with stock cPanel installations. You can tell the SiteGround guys to read this reply of mine: https://www.akeebabackup.com/my-tickets/ticket/akeeba-backup-3x/14525-command-line-backup-wont-finish.html#p84697 I think it will help them troubleshoot the issue. If they have any question, please forward it to me.

Another thing to point them to, from the cPanel forum: http://forums.cpanel.net/f5/jailshell-ulimit-issue-75265.html It seems that the user limits are not set in /etc/security/limits.conf but in /home/virtfs/user/etc/security/limits.conf. This would explain why the support told you there are no limits. They'd have looked at the /etc/security/limits.conf file. Too bad I don't have root access to a cPanel host anymore to see if my hunch is correct :(

OK :)