Using Cron To Automate Tasks On a VPS
A standard procedure to run tasks in the background on Linux machines is using cron jobs.
They are known to be useful for scheduling tasks on the VPS and also for automating various maintenance-related jobs. ‘Cron’ is, by itself, a daemon, or program, which runs in the background.
The routine for the different jobs so that the procedures run in a configuration file is called ‘crontab’.
Roughly all distros will have some form of cron installed by default. However, If you are with a system that does not have one installed, you can install it using the commands below.
sudo apt-get update
sudo apt-get install cron
For Cent OS/Red Hat Linux:
sudo yum updatesudo yum install vixie-cron crontabs
You will want to ensure it runs in the background as well:
sudo /sbin/chkconfig crond onsudo /sbin/service crond start
This is an example task you will have to run.
5 * * * * curl http://www.google.com
The syntax for the other jobs you will be placing in the crontab may seem intimidating. This will actually be very succinct and easy-to-parse if you happen to know how to read it.
The command is broken down into the following:
The command could be virtually any command you would regularly run on the command line. The routine component of the syntax is broken down into 5 various options for scheduling in the following order: – minute- hour- day of the month- month- day of the week
Below you will see a list of certain examples for a couple common schedules which you can encounter as you configure cron. To execute a command each minute.
* * * * *
To execute a command every 12th minute on the hour.
12 * * * *
You can also use various options for every placeholder. To execute a command every 15 minutes use the below.
0,15,30,45 * * * *
To execute a command every day at 5:00 am, you would use the below.
0 5 * * *
To execute a command each Tuesday at 5:00 am, you would use the below.
0 5 * * 2
You can use division in your schedule. Rather than listing out 0,15,30,45 you might as well use the following.
*/4 2-6 * * *
Note the ‘2-6’ range; this syntax will execute the command any hour from 2:00 am to 6:00 am.
The scheduling syntax is extremely powerful and flexible. You can easily express just about every possible time imaginable.
After you are settled with a schedule on the vps and you have an idea of the job you would like to run, then you will want to have an area to put it in so that your daemon will be able to read it.
You are going to have a couple of different places to choose from, although the most common is the user’s crontab. If you remember, this is a file which holds the schedule of jobs cron is going to run.
The files for every user are located at ‘/var/spool/cron/crontab’, though they are not really supposed to be modified directly, alternatively, it is better to use the crontab command.
You may modify your crontab using the following command.
This should bring up a text editor where you may input your schedule with each job on a new line.
If you want to view your crontab but not modify it, you can use the command below.
You can delete your crontab using the command below.
If you happen to be a privileged user, you may edit different user’s when specifying.
crontab –u <user> -e
For each cron job that gets executed, the user’s email address attached along with the user should get emailed the output, except in the case where it is directed into a log file or into ‘/dev/null’. The email address should be manually specified unless provided a ‘MAILTO’ setting at the top of the crontab. You can specify the shell you want to run, the path of the place to search for the cron binary and the home directory, by using the next example.
Modify the crontab.
Afterwards, edit it like shown.
SHELL=/bin/bash HOME=/ MAILTO=”[email protected]” #This is a comment * * * * * echo ‘Run this command every minute’
This specific job should output as shown.
“Run this command every minute.”
This output is going to be emailed each minute to the ‘[email protected]’email address specified.
It is not an ideal situation but, as we’ve mentioned, you can also pipe the output into a log file or into an empty location to prevent getting an email using the output.
To add to a log file, it is as simple as the following.
* * * * * echo ‘Run this command every minute’ >> file.log Note “>>” adds to a file.
If you would like to pipe into an empty location use ‘/dev/null’. This is a PHP script which gets executed and run in the background.
* * * * * /usr/bin/php /var/www/domain.com/backup.php > /dev/null 2>&1
Restricting access to cron is simple with the ‘/etc/cron.allow’ and ‘/etc/cron.deny’ files. If you want to allow or deny a user then you can just place their username in one of these files depending on the permit needed. By default, most cron daemons will assume all users have access to cron except if one of these files exists. To restrict permit to all users and to add access to the user test, you can use the following commands in sequence.
echo ALL >>/etc/cron.deny echo tdurden >>/etc/cron.allow
Now, you can restrict out all users by adding ‘all’ to the ‘deny’ file. Afterwards, add the username to the allow file, then add the user access to execute cron jobs.
You will see multiple shorthand commands which you can use in your crontab file to make administering a little easier. It is a fairly essential shortcut for the equivalent numeric schedule specified:
- @hourly – Shorthand for 0 * * * *
- @daily – Shorthand for 0 0 * * *
- @weekly – Shorthand for 0 0 * * 0
- @monthly – Shorthand for 0 0 1 * *
- @yearly – Shorthand for 0 0 1 1 *
Then ‘@reboot’ which will run the command once at startup.
Reminder: Not all cron daemons will parse this syntax, specifically older versions, remember to double-check this works so that you do not rely on it.
In order to have a job which runs on start up, modify your crontab file (crontab –e) and then place a line in the file similar to the below.
@reboot echo “System start up”
This specific command will get used and then emailed out to the user specified in the crontab.