In this tutorial, we will see how to set up repetitive tasks on your VPS. You may want to automate system maintenance or administration so that you
and so on. The command that will do all that for you is cron and the tasks are called cron jobs. Many popular software packages, will either ask you to fill in cron details or, like Drupal and Magento, will install cron jobs on their own.
yum install nano
Press y twice to finish the installation.
crontab, which is short for cron table, is a configuration file that defines shell commands to run periodically on a given schedule.
Cron may be system-wide or on a single user basis so there will be two kinds of crontabs, one for root user and the others for individual users. System-wide crontab will contain column for a particular user name, while crontabs for individual users will not.
On all three systems, the system-wide crontab is at /etc/crontab. You can edit cron jobs directly from this file but you actually shouldn’t. True automation will come only if each user has its own set of crontab files.
On CentOS, crontab files are stored in the /var/spool/cron directory while on Debian and Ubuntu, crontab files are stored in the /var/spool/cron/crontabs directory.
Here are the locations for cron jobs:
/etc/crontab
/etc/cron.d/
/etc/cron.daily/
/etc/cron.hourly/
/etc/cron.monthly/
/etc/cron.weekly/
/var/spool/cron/
/var/spool/cron/ contains a crontab file for each user who is using crontab.
Log files for cron runs can be found at the /var/log/cron.
Use this command to quickly see the contents of the crontab file:
cat /etc/crontab
Lines starting with # are comments.
Let’s analyse the contents of crontab file.
Lines such as
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
contain cron variables.
SHELL – it is possible to choose the shell that cron will run from. The default is /bin/sh.
PATH command, to denote where the system should look up when executing cron commands (see below). If PATH is blank, the entire path to the command must be explictly stated in the command itself.
HOME Normally, cron would execute the command from the user’s home directory. You can change the HOME variable to point to another directory.
MAILTO For each event, cron sends email notifications to the owner of the crontab. Specify a comma separated list of all the email addresses you want the notifications to be sent to. Put MAILTO=”” to deliver no mail at all.
Here is an example of a cron job with all these variables:
HOME=/opt
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/zsh
MAILTO=email@example.com
*/1 * * * * command
This command would execute every minute.
Columns in cron commands have the following meaning:
It is also possible to use
* Asterisk means any value or always. An asterisk symbol in the Minutes field will perform the each minute.
, Comma specifies a list of values for repetition. For example, if you have 1,13,15 in the Hour field, the task will be run at 1 am, 1 pm and 3 pm.
– Hyphen specifies a range of values. If you have 1-5 in the Month field, the task will run every month from January to May.
/ Slash specifies values that will be repeated over a certain interval between them. For example, if you have */4 in the Minutes field, the action will be performed every four minutes. The same effect would be to have had specified values of 0,4,8,12,16,20. You can also put a range of values before the slash. For example, 1-30/10 is the same as 1,11,21.
Imagine you are the system administrator and one of your users has started sending email marketing campaigns at the rate of 20,000 messages per hour. That may lead to poor experience for other users of your VPS, or you may want that user to just start paying more for the convenience. Or, you can restrict his crontabs on a user per user basis. That is where files /etc/cron.deny and /etc/cron.allow come into play. They contain a list of user names, one user name per row.
The /etc/cron.deny file exists by default and in the beginning it is empty. That means that all users of the system can use cron jobs. User with names listed in that file will not be able to use cron at all.
The counterpart file is /etc/cron.allow – only the users with names in it will be allowed to use cron.
If neither file exists, and depending on other system parameters, either only the super user will be able to use cron jobs, or all users would be able to use cron jobs.
Here is a handy command:
crontab -e
It asks to decide upon an editor and we choose nano.
Once in it, we see the crontab file contents:
The command is the same:
crontab -e
Choose nano amongst eight different editors that Debian offers:
You will end up in the same content as for Ubuntu, so we won’t repeat the image.
Use nano to edit the crontab file directly:
sudo nano /etc/crontab
and the contents of the crontab file are different:
Each time you change a crontab, you will need to restart the cron utility. Here are the relevant commands.
sudo service cron status
sudo service cron start
sudo service cron stop
sudo service cron restart
service crond status
service crond stop
service crond start
service crond restart
Here are the parameters of the crontab command:
crontab -e | Edit crontab file, or create one if it doesn’t already exist. |
crontab -l | Display crontab file contents. |
crontab -r | Remove current crontab file. |
crontab -i | Remove current crontab file with a prompt before removal. |
crontab -u | Edit other user’s crontab file. Must be run with system administrator privileges. |
Schedule a backup script to run every day at 5:30 AM:
30 5 * * * /path/to/script/backup-script.sh
To schedule the backup on the first day of each month at 8 PM:
0 18 1 * * /path/to/script/backup-script.sh
It is possible to use several macros to start events in the beginning of hour, day, week, and month.
@hourly path/to/script/script.sh
@daily path/to/script/script.sh
@weekly path/to/script/script.sh
@monthly path/to/script/script.sh
@reboot path/to/script/script.sh
The last line, with @reboot, will execute after server reboot.
In general, the script we execute as cron jobs will generate some output. We can save it log files, like this:
0 3,11,16 * * tue,sat path/to/script/script.sh > /path/to/logs/backup.log 2>&1
That command will execute on Tuesdays and Saturdays, at 3 AM, 11 AM and 16 PM and will save the output to a file called backup.log at the address /path/to/logs.
If we do not want to record any output, the command can look like this:
0 3,11,16 * * tue,sat path/to/script/script.sh > /dev/null 2>&1
We simply open the crontab file with nano, and enter one or more of the above commands in the end. Here is crontab file found in the fresh server install in Centos:
sudo nano /etc/cron.d/0hourly
Now enter the line shown above and you’ll get:
Save and close the file and that restart crond in this case. Of course, in real life you would put your own script address instead of path/to/script/script.sh.
Take a long and hard look at the way you are using your VPS and then surf around. You will find many repetitive tasks that you would like to automate so start using cron and crontab files as much as you can!
Dusko Savic is a technical writer and programmer.
The post How To Set Up Cron On Your VPS appeared first on Low End Box.
Debian and Ubuntu are two popular Linux distributions. In this deep dive we will guide…
In this article, we will see how to Install Google Cloud BigQuery Python client library…
Nov 15,2024 Wallpaper Contest for Xfce 4.20 open for voting The submission phase for the…
MicroCloud 2.1.0 LTS is now available, expanding the number of Canonical infrastructure solutions with a…
Canonical is thrilled to be joining forces with Dell Technologies at the upcoming Dell Technologies…
In today’s massive private mobile network (PMN) market, one of the most common approaches to…