Support

Hello,

the script is killed by their policies, the CLI process simply took too much time and after a while they kill the process, to avoid any zombie process to slow down the server.

What you have to ask them is to raise the limits for your Linux user (called ulimit), otherwise your user on the server is flagged for using too much resources (ie time) and gets killed. If that's not possible, you will have to use an external provider to trigger your backups, like WebCron.org

As they already know — because we've been through that with them when we were hosted there — the problem is not PHP's maximum execution time but the CPU time limits they have set up for each user account (as can be seen by running the ulimit -a command in an SSH session). They have set the CPU time limit to 600 seconds which means that backups on the CLI are killed after approximately 10 minutes. I don't say exactly because CPU time and wall clock time are different.

It is possible for their systems administrator to change the CPU time limit just for your user account to 3600 seconds which should be enough for you to run your backups. This is done by editing the file /etc/security/limits.conf (it's system-wide, that's why their systems administrator must do it). Since this file is read when a login shell is executed it will be applied automatically next time you run a CRON job.

There are more complicated ways to handle it on their side. For example they could set a soft limit of 600 seconds and a hard limit of 3600 seconds which means that by default you only get 10 minutes of CPU time but you could also change your CRON command line to read:

ulimit -t 3600; your_current_command_line_here

The first part says "raise my soft CPU time limit to 3600 seconds, then execute the other command after the semicolon". This is preferable to prevent runaway processes from bogging down the server.

You're welcome! Let me know if you need help on this issue