Times to avoid
See information here about weekly reboots and take that in to consideration when scheduling cronjobs.
Scheduling cronjobs for between 01:00 and 02:00 is best avoided. The changes between GMT and BST mean there is one day a year when that hour doesn't happen and one day a year when it happens twice. Documentation for the cron implementation used on Linux Hosting servers says that a job scheduled at 01:30 should run only once during the switch from BST to GMT. When the switch GMT to BST happens it should get run at 02:00. However, many discussions about undesirable handling of cronjobs scheduled during hours affected by daylight savings can be found online, so if it's critical that the job always runs once at exactly the time specified, don't schedule it between 01:00 and 02:00.
If you schedule cronjobs as the admin user, the email will be sent to admin@hostname_of_your_server and those emails will be delivered to the email address of the person have recorded as the admin contact for the server.
You can check the address these emails are sent to by checking the /etc/aliases file.
[admin@foo ~]$ grep ^admin /etc/aliases admin: email@example.com [admin@foo ~]$
In that example emails sent to admin@foo are delivered to firstname.lastname@example.org
You can control where output of cronjobs is sent by adding a line at the start of the crontab
You can specify a comma separated list of addresses.
You can send the output of different cronjobs to different email adresses. E.g.
* * * * * echo "hello you"
* * * * * echo "hello someone"
Cronjobs for the admin user are run in an environment with the following environment variables set
XDG_SESSION_ID=NNN SHELL=/bin/sh USER=admin PATH=/usr/bin:/bin _=/usr/bin/env PWD=/home/admin LANG=en_GB.UTF-8 HOME=/home/admin SHLVL=2 LOGNAME=admin XDG_RUNTIME_DIR=/run/user/1000
You can set PATH by adding a line at the start of the crontab.
If a command you want to use in a cronjob is provided by a Software Collection, it will not be available to use in scripts called from cron unless you explicitly make it so. Software Collections may have been installed on your server as a result of you requesting a newer version of a package than is included in the version of CentOS your server runs. You can check if this is the case as the command will live somewhere under /opt/rh/ E.g.
[admin@mike-test1 ~]$ php --version PHP 5.6.5 (cli) (built: Aug 30 2016 13:52:26) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies [admin@mike-test1 ~]$ which php /opt/rh/rh-php56/root/usr/bin/php [admin@mike-test1 ~]$ /usr/bin/php --version PHP 5.4.16 (cli) (built: Aug 11 2016 21:24:59) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies [admin@mike-test1 ~]$
The above shows that the php command is being provided by the rh-php56 Software Collection. (rh-php56 appears in the path after /opt/rh/) Note that in this case there are two versions of PHP installed so if you call something from cron that invokes 'php' without a full path, it'll run with PHP 5.4.16, which probably isn't what you're expecting (see the value for PATH in Environment section above).
If you want to use /opt/rh/rh-php56/root/usr/bin/php in a cronjob it is NOT sufficient to simply specify that using the full path. If you do that it will not be running in the environment defined by the Software Collection it is part of. You need to enable the relevant Software Collection before PHP is invoked. There is more than one way that this can be achieved. You may find that one method better fits your workflow than the others.
[admin@mike-test1 ~]$ crontab -l PATH=/usr/bin:/bin:/home/admin/bin # solution 1 * * * * * scl enable rh-php56 "php --version > /tmp/phpcronversion.txt" # solution 2 * * * * * scl enable rh-php56 phpfoo > /tmp/phpfoo2version.txt # solution 3 variant * * * * * phpfoo2 > /tmp/phpfooversion.txt [admin@mike-test1 ~]$ cat bin/phpfoo #!/bin/bash php --version [admin@mike-test1 ~]$ cat bin/phpfoo2 #!/bin/bash source scl_source enable rh-php56 php --version [admin@mike-test1 ~]$
All of these methods result in PHP 5.6 being used.
[admin@mike-test1 ~]$ cat /tmp/phpcronversion.txt PHP 5.6.5 (cli) (built: Aug 30 2016 13:52:26) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies [admin@mike-test1 ~]$ cat /tmp/phpfoo2version.txt PHP 5.6.5 (cli) (built: Aug 30 2016 13:52:26) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies [admin@mike-test0 ~]$ cat /tmp/phpfooversion.txt PHP 5.6.5 (cli) (built: Aug 30 2016 13:52:26) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies [admin@mike-test1 ~]$
These methods are adapted from https access.redhat.com/solutions/1252913 (N.B. at time of writing the Resolution section shows the arguments to the scl commend the in the wrong order so the suggested solutions shown don't actually work.)