11.8. Administration Is So Repetitive
The first time you run a job, it's helpful to do it manually. The more you do a job yourself, the more you learn about that job.
However, once you've run a job a few times, there's little more that you can learn about that job, as least in your current environment. At that point, it's best to automate the process. Linux already has a service that runs automated jobs on a regular basis, whether it be hourly, daily, weekly, or monthly.
Another reason why you want to automate tasks is so you can go home. With appropriate logs, you can make sure the job was properly executed when you return to work. Thus, you can configure a database job to run once per year, so you don't have to be at work on New Year's Eve.
Finally, when you administer a group of systems, the number of things you have to do can be overwhelming. Automation is often the only way to keep up with what you need to do. This is why you need to learn to manage the cron service.
11.8.1. Basic cron Jobs
It's easy to learn the workings of the cron service. Every Linux system includes numerous examples of cron jobs. The cron daemon wakes up every minute Linux is running, to see if there's a script scheduled to be run at that time.
Standard administrative jobs are run as scheduled in /etc/crontab. Red Hat and Debian configure this file in straightforward ways, with different command scripts for hourly, daily, weekly, and monthly jobs. The format starts with five time-based columns, followed by the user and the command:
minute / hour / day of month / month / day of week / user / command
Take a look at your own version of this file. While it varies by distribution, all use a variation of the same first two directives, SHELL and PATH.
SHELL=/bin/sh SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin PATH=/sbin:/bin:/usr/sbin:/usr/bin PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
Both SHELL directives point to different names for the default bash shell. The PATH directives provide the baseline for other scripts executed from the embedded directories by the cron daemon. The simplest version of this script is associated with Red Hat/Fedora distributions:
01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
These directives point to the run-parts command, which runs the scripts in the noted directories, as the root user. While you could use the full path to the command (/usr/bin/runparts), that's not necessary because /usr/bin is in the PATH, as cited at the beginning of this file.
In this case, hourly scripts are run at one minute past every hour, daily scripts are run at 4:02 A.M. every day, weekly scripts are run at 4:22 A.M. every Sunday, and monthly scripts are run on the first day of each month, at 4:42 A.M.
While Debian and SUSE run more complex versions of this script, the effect is essentially the same. On our preferred Linux distributions, the cron daemon runs the scripts in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly directories. Many scripts in these directories use the full path to all commands, despite the PATH directive in /etc/crontab.
11.8.2. Creating a cron Job
You can create a cron job in any of the aforementioned directories, and it will be run at the intervals established in /etc/crontab. To help you understand how all this works, I'll create a yearly cron job, with the following steps:
Any output from a cron job is sent to the user as an email. Most standard cron jobs you'll find in the directories discussed here are carefully designed not to create any output, so you won't see email from them. cron jobs suppress such output by redirecting both standard output and standard error to files (or to /dev/null).
18.104.22.168. User-specific cron jobs
Users can create and schedule their own cron jobs. As a regular user, you can open a cron file for your account with the following command:
Use the steps described in the previous section to create your own cron job. With the appropriate SHELL, PATH, and commands, you can run the scripts of your choice at the regular times of your choosing. To review your account's crontab configuration, run the following command:
Naturally, most regular users won't understand how to create their own cron jobs. As the administrator, you'll have to create the jobs for them. For example, if you want to create a job for user nancy and have administrative privileges, run the following command:
crontab -u nancy -e
However, for any user to access individual cron jobs, he needs permission. There are several ways to configure permissions to use cron:
What you do depends on whether some of your users need to create cron jobs, and whether they are capable and trusted to do their own cron jobs (or whether you're willing to create cron jobs for your users).
If you want to see how cron jobs are configured, check them out for all users in your spool directory. The actual directory varies slightly by distribution. Red Hat/Fedora uses /var/spool/cron/username, SUSE uses /var/spool/cron/tabs/username, and Debian uses /var/spool/cron/crontabs/username.