Using Cron to Schedule 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 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!
As mentioned above, each Linux user has their own . Initially, this file will be empty and you can check the contents of your 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:
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.
You can edit your 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.
Cron is a pretty straightforward utility and generally, the problems I've seen fall into two categories:
- The job did not run at the scheduled time
- 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).