Cron job error

And by the way, does it matter if the site still has a temporary url with something similar to this link.

https://xx.xxx.xxx.xxx/~temp/wp-content/plugins/akeebabackupcore/app/index.php?view=remote&key=somekey

I also tried running this under https://webcron.org/, it shows Internal Server Error. So I believe the error is in the script itself and not with the server.

The CRON job works on all of my sites including my local dev sites and my on-line blog site. Unfortunately without telling me what “error in the middle of the process” actually means I can’t possibly help you.

Thanks Nikolas for responding. I actually didn’t know what error message to give as it didn’t show anything except the red “failed” text.
https://postimg.org/image/tvk5r8kix/

Content of log file:
WARNING: Do not copy and paste lines from this file!
You are supposed to ZIP and attach it in your support ticket.
If you fail to do so we may not be able to reply to your ticket in a timely manner.

— START OF RAW LOG —
— END OF RAW LOG —

I tested it on webcron and what shows is “Internal Server Error”
https://postimg.org/image/nshvxger7/

I can’t really say that it’s a server issue because all of our Joomla sites hosted on the same server work perfectly using the same “WGET” script for cron jobs.

This (complete lack of) log file means that the backup never even started. We’re not talking about an “error in the middle of the process”, we’re talking about your server never routing the request to the backup software. Since I don’t know your server setup I can’t help you much. Most likely it’s a problem caused by the temporary URL. Maybe it’s something from a .htaccess in your account root, the website’s root or any of the wp-content, wp-content/plugins, wp-content/plugins/akeebabackupcore or wp-content/plugins/akeebabackupcore/app directories. I’m sorry I have to be so vague but that’s exactly as precise as I can be with the information I have at hand.

It looks like the error is caused by the following:

1. It does not allow creating a backup folder outside of AKEEBABACKUPCORE.
I used the default folder instead. With joomla, it’s always been my habit of creating a separate folder for the backup files.

https://postimg.org/image/uwtthp6sz/

2. I add new cron job in webcron.org and set timeout=600
Not sure if I can set timeout in server’s cron settings. I’ll have to do some research on wget timeout format.

I tested this on both live domain and temp domain provided by hosting. I left for 30 mins and when I came back, ALAS, both frontend backup were successful.

1. This is NOT absolutely correct. All versions and editions of our backup software do allow you to select off-site backup directories. I am never using the default backup directory. I even warn you in our documentation not to use the default backup directory. A backup output directory above the site’s root is the best choice as long as your server supports it.

On certain servers you have open_basedir restrictions and/or a server permissions setup which does not allow you to create a backup output directory above the site’s root. If there are open_basedir restrictions then yes, trying to use an off-site backup output directory WILL lead to a 500 Internal Server Error. Please ask your host to lift the open_basedir restrictions. It’s an architecturally incorrect way to implement security –according to the fine people writing the PHP language– and it’s removed from the upcoming PHP 7 version for this reason.

2. These are two different things. The timeouts involved in a backup are:

a. The PHP max_execution_time timeout. It affects the maximum time each backup step can execute. A value of 10 or more is recommended. Akeeba Backup can work on small sites even with a max_execution_time around 5 seconds. Anything below 5 seconds is impractical for your site, not just Akeeba Backup. This limit is set up on your server and usually can be overridden through a php.ini or .user.ini (mind the dot in front of user!) on your site. For more information please contact your host.

b. The CRON server’s own timeout. It affects the total time the backup is allowed to run. If your backup takes 15 minutes to complete (900 seconds) but your CRON timeout is lower (e.g. 600 seconds) then it stands to reason that the backup will NOT complete successfully: the CRON job will be terminated before the backup has the chance to complete. The simple way to figure out the desired limit is take a backend backup, go to Manage Backups page, see the time recorded there, multiply it by 1.1 and consider this as the lowest possible CRON timeout setting.

Nikolas, In the screenshot I posted at https://postimg.org/image/uwtthp6sz/, you will notice that the folder I selected was inside /public_html/ but it still showed a note saying “This Directory is outside of your site’s root”. That is why I decided to set it back to the default folder and test again. I tried this on two different websites with the same message. I thought at first that it might be a bug. But anyway, I will communicate with the host as you suggested.

Thank you once again for taking time to reply to this post.

The notice is normal. Since there are some hosts which apply restrictions like the ones I mentioned above –and which cannot be detected reliably without risking the detection code resulting in a blank page / 500 error which brings down the entire component– the only thing we can do is show a warning by default. FYI, this behaviour is defined in the backup engine which is the same that’s being used in the Joomla! extension you were familiar with. If you go to your Joomla! sites you’ll see it there too ??

I guess I was being too familiar with Akeeba for Joomla that I just didn’t mind all the notes and warnings. ??

Yes, that’s called “conditioning”. You get used to something that you literally become blind to it ??