SCHEDULING PROCESSES

Often you may have to run jobs at particular times such as taking a backup or to run certain scripts at startup. It is nearly impossible to be glued to a terminal to run these scripts. This is where cron comes in.

About

cron is a *nix program that allows users to execute commands on a regular basis based on a particular date and time. It is typically used for system maintenance or performing server administration, but it can be used by application developers to run certain processes such as generating invoices or downloading updated data from the internet.

Most Linux flavors have cron installed by default, but if you don’t it is easy to install it

# apt-get install cron # Ubuntu/Debian

# yum install cronie # CentOS/RHEL

Please note that the daemon name in CentOS is crond and this will be the service that is running and not cron. You will also hear the term crontab, which is an utility to edit the schedule. It is also the name of the file where the cron rules are stored.

On some RHEL based systems, the /etc directory might contain subdirectories called cron.hourly, cron.daily, cron.weekly and cron.monthly. The scripts in each sub-directory is processed based on the time period it denotes. For e.g. if you placed under cron.weekly directory, it runs once every week.

To run a job as a one-time basis, you can use the at utility instead of cron

Access to cron

By default, root users have access to cron and can edit and add rules. Other users may or may not have access. There are two files located under /etc directory called cron.allow and cron.deny which contain the list of users who can or cannot access cron. If these files don’t exist, it depends on the server configuration if all users have access or only super users do.

If you need to explicitly give access to a particular user

# echo userneedscron >> /etc/cron.allow

In this example, since we haven’t created an explicit cron.deny file, the system processes it as ALL regular users are denied access to cron except userneedscron.

Setting up a CRON rule

Schedules in a typical cron job following a set pattern

Minute(0-59) Hour(0-24) Day_of_month(1-31) Month(1-12) Day_of_week(0-6) 
Command_or_script

Or, for the system level cron job

Minute(0-59) Hour(0-24) Day_of_month(1-31) Month(1-12) Day_of_week(0-6) user-name 
Command_or_script

Each field can have a value or be set to * which means all values in that range qualify. * in the Day_of_month field means the command or script executes on all days. On a new server, you may not have any active cron jobs setup. Let’s start by adding a new schedule. The command to edit the crontab file is crontab itself with the parameter -e

# crontab -e

When you invoke this for the first time, you will be asked to choose the default editor.

no crontab for root - using an empty one

Select an editor. To change later, run 'select-editor'.

1. /bin/nano <---- easiest

2. /usr/bin/vim.basic

3. /usr/bin/vim.tiny

4. /bin/ed

Choose 1-4 [1]:

I am more comfortable with nano, but you could choose the editor of your choice. You edit the crontab file similar to any regular file as long as you follow the format

# ┌───────────── minute (0 - 59)

# │ ┌───────────── hour (0 - 23)

# │ │ ┌───────────── day of the month (1 - 31)

# │ │ │ ┌───────────── month (1 - 12)

# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;

# │ │ │ │ │ 7 is also Sunday on some systems)

# │ │ │ │ │

# │ │ │ │ │

# * * * * * command_or_script

I mentioned that * means all possible values in the range, let’s see some other possible values. (All asterisks means the job runs every minute)

If you want to run a job every hour on the hour, you choose minute 0, i.e. beginning of the hour

0 * * * * /opt/myapp/checkstat.sh

By changing 0 to a different value, say 10, it would make the script run every hour at 10 minutes past the hour. This way you can allow for a previous cron job to complete (let’s say it runs on the hour) before you trigger the next step.

To run a daily job, at a particular time

15 1 * * * /opt/myapp/backup.sh

This script runs at 1:15 AM everyday

You can run jobs monthly by passing the day of the month in the third field.

0 0 5 * * /opt/myapp/sendemail.sh

In the above, we run the sendmail script on 5th of every month at midnight.

Another combination is to run a job only on a Sunday.

0 1 * * 0 /opt/myapp/updateinv.sh

This job runs only on a Sunday, and at 1 AM.

Now that you have a hang of how to use cron, I am going to add some more operators. Let’s start with a range. Say, we need to run a job three times every hour, once on the hour, again at 20 past and then at 40 past.

0,20,40 * * * * /opt/myapp/twentymin.sh

The next operator is the slash operator that divides the range into the number you specify. If you need a job to run every 5 mins, it will take you ages to compose 0,5,10,15 up until 55. It is easier to

*/12 * * * * /opt/myapp/fivemin.sh

The range 60 is split into 12 and cron executes the script accordingly.

Finally, the range operator specified by a hyphen (-). You want to run a job every minute for the first 10 minutes of the hour?

1-10 * * * * /opt/myapp/myscript.sh

You can combine this with the comma operator and specify multiple ranges

1-10,20-29 * * * * /opt/myapp/myscript.sh

If you wanted to run a command or script when the system reboots such as sending you an email that the system was rebooted, you can use the special keyword @reboot

@reboot /opt/myapp/restarted.sh

Once you added your rules and save the file, crontab automatically validates the rules and notifies you if any rules are invalid.

Upon a successful save, you can list the active rules by issuing

# crontab -l

Finally, if you want to clean out your cron table and start from a blank page, you can issue

# crontab -r

I hope this gives you a good introduction to setting up processes to execute based on a schedule. If not for any particular app, for running an rsync backup to an offsite location.