The following commands would apply to the user which you are logged in as. For example, if you are logged in as "root", these commands would pertain to root's crontab file.
crontab -e - opens the user's crontab file for viewing/editing
crontab -l - simply lists the crontab file's contents for the user. Think of it as a "cat" function for the crontab.
crontab -r - removes the crontab file contents for the user
But what if you want to edit another user's crontab?
The system administrator is usually logged in as "root", but making changes to another user's crontab file or simply looking at another user's crontab file is often necessary. For situations like this, you can append the "-u" flag followed by the desired username.
For example, if logged in as root but you want to edit the crontab for the user "admin", you would do the following:
crontab -e -u admin
The same logic applies to the other crontab commands as well, such as:
crontab -l -u admin - lists the crontab entry for the "admin" user.
crontab -r -u admin - removes the crontab entry for the "admin" user.
Writing to the Crontab
Now that you know how to access the crontab, let's take a look at the syntax of the crontab entry itself.
A typical crontab entry might look like this:
30 0,12 * * * /usr/local/scripts/whatever.script
OK, so what does that mean? Well, there are 2 parts to the entry you see above. In fact, any crontab entry has 2 parts:
Part 1 - The schedule
The schedule, which governs when the task will run, consists of a string of numbers, possible commas and asterisks (*).
So, in the above example, the schedule is:
30 0,12 * * *
What you are seeing is actually split up into 5 sections. The following chart illustrates what each section of the schedule is for:
1. Minute - Minutes after the hour (0-59).
2. Hour - 24-hour format (0-23).
3. Day - Day of the month (1-31).
4. Month - Month of the year (1-12).
5. Weekday - Day of the week. (0-6, where 0 indicates Sunday).
* = An asterisk in a schedule field indicates "every". It means that the task will occur on "every" instance of the given field. So a "*" on the Month field indicates the the task will run "every" month of the year. A * in the Minutes field would indicate that the task would run "every" minute.
, = A comma is used to input multiple values for a field. For example, if you wanted a task to run at hours 12, 15 and 18, you would enter that as "12,15,18".
Let's take a look at how this format fits into the syntax of a crontab entry:
_________________________ 1. Minute - Minutes after the hour (0-59)
|
| ______________________ 2. Hour - 24-hour format (0-23).
| |
| | ___________________ 3. Day - Day of the month (1-31)
| | |
| | | ________________ 4. Month - Month of the year (1-12)
| | | |
| | | | ______________5. Weekday - Day of the week. (0-6, where 0 indicates Sunday)
| | | | |
30 0,12 * * * /some/script/or/command
So, when we combine all the schedule elements, we know when and how often this task will run. Going on the above example, this task would run:
At 30 minutes past the hours of 0 (midnight) and 12 (noon), EVERY day of the month, EVERY month of the year and EVERY day of the week.
In other words, the above task would run every single day at 12:30AM and 12:30PM.
Let's play around with the schedule a little bit and try something different. What if we had something like this:
15,45 0,12,6 20 1,2,3 0 /some/script/or/command
Wow! Now this is a pretty complex crontab entry. Let's decipher it...
15,45 - This means that the task will run at 15 and 45 minutes past the hour. But what hours and what days? Well, that's coming up.
0.12.6 - The task will run during the hours of 0 (midnight), 12 (noon) and 6AM.
20 - The task will run on the 20th day of the month. But during what months?
1,2,3 - The task will run only during the months of January, February and March.
0 - The task will only run on a Sunday.
So, when we put all of this information together, here is what it boils down to:
This task is going to run at 0:15, 0:45, 6:15, 6:45, 12:15 and 12:45 on the 20th of January, February and March IF that day falls on a Sunday. Pretty cool, huh?
Part 2: The task itself
This is pretty self-explanatory. In the above example, the "task" to run would be: /some/script/or/command.
Now obviously, that's not a real script or commnad, it's just an example that you would fill in the blanks for. Generally, there are 2 ways to run a task from the crontab:
Method A: Run the desired command directly from the crontab
Here's an example of running a command directly from the crontab:
*/15 * * * * /sbin/ifconfig | mail myname@mydomain.com
This is pretty cut and dry. This entry is going to run the "ifconfig" command and then pipe the results out to an e-mail that gets sent to myname@mydomain.com. This task will run EVERY 15 minutes, EVERY day, EVERY month, EVERY day of the week. In other words, this task runs every 15 minutes.
As you can see, the "ifconfig" command is called directly form the crontab entry. This is fine is you are running a simple command. But what if you need to do more than that?
Method B: Run a script from the crontab that runs the commands.
Here's an example of running a script from the crontab. The script that you run, in turn, executes whatever instruction you might want:
15 0* * * /usr/local/scripts/run_webstats.script
As you can see, every night at 0:15, this task runs a script called "/usr/local/scripts/run_webstats.script". That script, as you may guess, generates the webstats for the website on the server. The crontab runs a script and then the script contains the actual instructions on what the task is supposed to do. Get it?
By the way, I'm just making these crontab scripts up out of thin air, so don't expect the above example to really work. You would need to replace my bogus script calls with REAL scripts calls or commands.