In Unix, to run a script at some regular interval, notate it in a crontab file. A crontab file is a list of programs that cron should run at specified times.
Cron itself is an OS service that runs scheduled jobs, those in any one of a number of crontab files on the machine. It is Unix daemon–It basically wakes up every minute, looks to see if any jobs need to be completed. If there are, it starts the job. If not, it goes back to sleep.
To find if cron is running on your system, type in, at the command line “ps -aux,” which will give you a list of all the processes running on the machine. Look for the name cron under the far-left column, called commands i.e.
root 4556 0.0 0.2 2100 888 ? Ss Feb17 0:01 /usr/sbin/cron
While there a few ways to get cron to execute a job (cron is another topic) , crontab is one way to get the job done. Like I said, crontab is basically a list of scripts, commands and programs that Unix can execute.
In Ubuntu (as w/ most other Linux distros), you edit the crontab file directly, by evoking it from the command line, i.e.:
#crontab -e
Listing jobs in crontab can be done by typing in:
#crontab -l
Anyway, when you edit, you will get a file. It may already have some jobs in it, i.e.:
# m h dom mon dow command
17 * * * * echo “hello”
In the first block above, the line (“# m h dom…”) is a header that is the key to explaining each of regularly scheduled jobs that will follow in subsuquent lines. m=minute, h-hour, dom=day of month, mon=month, dow=day of week, and command is the command or program that will be executed at the time indicated on the left.
Each job gets its own line. You add a job to be scheduled by adding a new line.
In the first five columns that specify time, “*” is null–means that column is unset. All the values are numeric and occasionally 3-letter abbreviations (i.e. week is 0-7 [0 & 7 = Sunday], though can also be sun “Sun”; month is 0-12 can also be name of the month. Hour is 0-23, with 23 being midnight).
After the first five entries are filled out, indicating when the job is to be run, the rest of the line is the job itself, expressed as a standard command line statement: It can be a command or series of commands that need to be run, or a program w/ the pathname.
In the above example, the command (“echo ‘hello’”) is run on the 17th minute of each hour. It prints the word “hello” on the screen.
With the day/week/month, you should specify on what time that job executes (If you run two times, say a day of of week and a day of the month, cron will run twice unless they fall on the same day). If you don’t specify what day/week/month, it will run every day, at the time you specify. You can also specify times -per unit, i.e., in the minute column, you can write “*/10″ to signify to run the job every 10 minutes.
(UBUNTU note: The User Geeks page says the crontab file is found in the /etc folder. Ubuntu’s own documentation advises you not to use this file–evidently it can be replaced by updates. Maybe it is only used for the configuration settings)
So, for instance, say I want to run a script, called “backup,” which backs up my files to another location. I want it to run, say, once a day (I don’t want to back up too often, in case I mess up a file, I can quickly retrieve). I’m usually never awake at 3:20 a.m., so I’ll specify that time each day. My new line in the crontab would look like this:
m h dom mon dow command
22 3 * * * /home/jobs/backup
If you want to run multiple commands simultaneously, use the “&&” between the two commands.
Getting a log file of your cron jobs
If you want a record of how things went, you can specify a (plain text) log file that can write out any results that would have otherwise be returned from the command line. You add the “>>” onto the end of your job, followed by the name of the log file, and its location:
30 16 * * * root /root/scripts/ServerBack >> /root/scripts/backup.log
NOTES:
*Ubuntu server does not initially allow user access to cron. In order to get Cron, you can either put the user name in a file called cron.allow, in the /etc directory, and create a cron.deny and not put that user name in that file.)
*If things aren’t running properly, check the var/log/syslog file for any error messages. For instance, my crontab entries did not work under root. When checking the log I found the
Mar 29 22:26:01 warehouse CRON[20531]: User account has expired
According to this article, when you lock a user account (so that it can’t be accessed externally), it also “expires” the password (Note: This isn’t a problem with Ubuntu out the box–it only happens when you unlock, then lock the root account). The log entry suggested running this command:
#chage -E-1 root
Which permanently unlocks the password. I have no idea *why* this works, but it has.
*For purposes of backup, you should track down the crontab files for each user (Again, this is not in the etc/ folder), so they can be saved. Beats rewriting them again when you set up a new server.
–Joab Jackson
And now, a word from our sponsor: