Using Crontab
Crontab is an incredibly useful function that allows users to schedule tasks in the same way as the system does with cron. Each user has their own crontab that they can maintain and edit. To view your crontab simply use:
crontab -l
You can edit your crontab file in a similar fashion using:
crontab -e
However, I've noticed on my Mandriva system that in a default configuration utilizing this command results in a rather cryptic error message that reads:
[justin@paris ~]$ crontab -e You (justin) are not allowed to use this program (crontab) See crontab(1) for more information
This odd behavior is the result of a missing /etc/cron.allow and /etc/cron.deny file. These files govern the behavior of user crontabs. Crontab behaves using a 'default deny' model, so any user not explicitly listed in the cron.allow can't use crontab (even if neither the cron.allow or cron.deny exist). In order to allow users to edit the crontab simply create a cron.allow file and add the username to that file. The easiest way to do this is using:
[justin@paris ~]$ sudo echo justin >> /etc/cron.allow
And then you'll be able to use the crontab. Note that each crontab is distinct so you won't be able to edit any crontab other than your own.
Users of Mandriva will also notice some other interesting directories in /etc that have to do with cron. The following show up in /etc:
cron.d/ cron.hourly/ crontab cron.yearly/ cron.daily/ cron.monthly/ cron.weekly/
The cron.d is empty, but presumably this space is for configuration information. Each of the other directories contain scripts that are scheduled to run, you guessed it, daily, hourly, monthly, weekly, and annually. It's fairly easy to run through these scripts and read up on what they do. You might be left wondering, however, how these scripts end up being called in the first place. In fact, they're called via the crontab in /etc/crontab. You can view this file using:
[justin@paris ~]$ sudo more /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root nice -n 19 run-parts --report /etc/cron.hourly 02 4 * * * root nice -n 19 run-parts --report /etc/cron.daily 22 4 * * 0 root nice -n 19 run-parts --report /etc/cron.weekly 42 4 1 * * root nice -n 19 run-parts --report /etc/cron.monthly
And you can see each of these is conveniently scheduled to run as root using the 'nice' command. Nice "run[s] a program with modified scheduling priority." This means that you can adjust the aggressiveness of the commands so that they don't interfere with other things that are going on on the server.
Nice assigns a priority of 19, then kicks off another program called 'run-parts'. Run parts is a program that will run all the scripts in a target directory. The '--report' option prints extra output (the name of the scripts) along with the script output itself.
So as you can see the first entry runs nice, which runs, run-parts, which in turn runs all the scripts in /etc/cron.hourly. Cron is configured with the first four lines in the /etc/crontab file. In this case the path is set, the default shell is set and the output of any cron job is mailed to 'root'. The HOME environmental variable is useful to set if there is any output of the scripts. Set to the root directory like it is, means that any scripts that simply dump output files into the current working directory will actually end up at the root directory.
Knowing how this configuration works you can also use the various directories to run your scripts. Instead of creating a script and then scheduling it explicitly in cron or a user crontab you could simply drop the script into the appropriate directory and have it piggyback on the default scripts provided.