Linux Topic
   >  Shell Scripts
   >  Using Comments
   >  Passing Arguments to Scripts
   >  Using Conditional Statements
   >  Using Loop Statements
   >  Reading and Writing Files
   >  Script Permissions
   >  Cron and Scheduling
   >  A Scripting Example
   >  Other Scripting Languages


Using Cron to Schedule Scripts

Using Cron to Schedule the running of Scripts

Linux provides a scheduling utility called Cronto allow scripts to be run periodically. You can run any command, executable or script file at any time and day you require - and as many times as you like! It is a really flexible system which is simple to use and control.

Each Linux user has their own crontab file which defines what commands will be run for that user and when. Each user can see / edit only their file (-unless they are a privileged user such as "root"). The administrator can also deny all or certain users from being able to use cron (-via the cron.allow or cron.disallow files).

It is perfectly possible for multiple users to schedule completely different jobs to run at the same time and Linux will take care of everything in the background!

Note: when running cron on a desktop, be aware the times you PC is actually on and running! For servers which are up 24x7, jobs can be scheduled at any time but if you schedule a job to run when your machine is down, it will not run!

The Crontab File

As mentioned above, each Linux user has their own crontab. Initially, this file will be empty and you can check the contents of your crontab by typing:

$ crontab -l

-or, if you happen to be logged on as the root user, you can see other users' crontabs by typing:

$ crontab -l -u <username>

If there is nothing scheduled for this user, then nothing will be returned from this command. If you do have something set up, it will be printed out to the screen, for example:

$ crontab -l
# Edit this file to introduce tasks to be run by cron.
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# For more information see the manual pages of crontab(5) and cron(8)
# m h  dom mon dow   command
0 0 * * * /home/fredb/mycommand -i -z /var/tmp/inFile

This looks a little intimidating, until you realise that all lines starting with a hash (#) sign are comments! So, in the example above, there is only job listed - on the very last line:

0 0  * * 0 /home/fredb/mycommand -i -z /var/tmp/inFile

All lines in the crontab follow the same format:

<minute of the day> <hour of the day> <date of the month> <month of the year> <day of the week[0-6]> <command to run>

If you put an asterisk (*) in any of these fields, it means you want the command to run for all values of that field. In the example we used above, we stated that we wanted to run the command "/home/fredb/mycommand -i -z /var/tmp/inFile at midnight (hour=0, minute=0) every Sunday (day=0).

Note: The crontab file is actually a lot more flexible than shown above. If you require even more flexible scheduling than the above (-or just want to know more), check out the Crontab Man Page on the web.

Changing the Crontab File

You can edit your crontab file by typing:

$ crontab -e

You may well be asked which editor to use (Ubuntu gives me three options: 1-3). Once selected, you will be placed in that editor, with the crontab open. Simply make the changes you require - as you would with any other text file - and save the changes before you exit.

Troubleshooting Cron Issues

Cron is a pretty straightforward utility and generally, the problems I've seen fall into two categories:

  1. The job did not run at the scheduled time
  2. The job did not run correctly under cron, whereas it works fine from the command line

For case 1, you should check that the system time is set correctly (-by issuing the date command and if that looks correct, check if the system was actually powered up at the appointed time.

For case 2, the problem is often that cron does not run the usual startup scripts for a user before running a job (-such as .profile , etc). In this case, either run the user setup scripts explicitly from within your own script -or fully qualify all filenames and commands in the script (-i.e. do not rely on anything in your $PATH).

HomeSite IndexDesktop GuideServer GuideHints and TipsHardware CornerVideo SectionContact Us

 sitelock verified Firefox Download Button