Section 11.8. Administration Is So Repetitive


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:

As SUSE's /etc/crontab calls the /usr/lib/cron/run-crons script, the following steps (at least after step 6) won't work in that distribution.


  1. Log in as the root user. (Alternatively, if your regular account is in the /etc/sudoers file, you can log in as a regular user and use the sudo command to invoke the commands in this section.)

  2. Create a /etc/cron.yearly directory, with the same ownership and permissions as the other related directories. As those directories are owned by root and have 755 permissions, they happen to be compatible with standard root permissions for new directories. So all that is required is:

     sudo mkdir /etc/cron.yearly 

  3. Create a new script in the /etc/cron.yearly directory. I'd call it happynewyear. Include the following commands in that script (which saves the files from user donna's home directory in user randy's home directory):

     #!/bin/sh /usr/bin/rsync -aHvz /home/donna /home/randy/ 

  4. Save the file. Make sure the script is executable with the following command:

     chmod 755 /etc/cron.yearly/happynewyear 

  5. Test the script. Run it using the full path to the script:

     /etc/cron.yearly/happynewyear 

  6. Now make sure it runs at the next new year. Open your /etc/crontab and make a copy of the directive that runs the monthly cron scripts in /etc/cron.monthly. Change the directory to /etc/cron.yearly, and modify the time the script is run to something appropriate. For example, I use the following line in my Red Hat Enterprise Linux 4 system:

     2 0 1 1 *  root run-parts /etc/cron.yearly 

    This directive runs the script at two minutes past midnight on January 1. As the day of the week associated with New Year's Day varies, the last time entry has to be a wildcard. I chose two minutes past midnight because the directive associated with the /etc/cron.hourly directory is run at one minute past midnight.

  7. Save your /etc/crontab configuration file.

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).

11.8.2.1. 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:

 crontab -e 

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:

 crontab -l 

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:

  • If there's an empty /etc/cron.deny file (and no /etc/cron.allow file), all users are allowed to have individual cron jobs.

  • If there is no /etc/cron.deny or /etc/cron.allow files, only the root user is allowed to have cron jobs.

  • If there are specific users in /etc/cron.deny, they're not allowed to use cron jobs, and the root user isn't allowed to create a cron job for them; all others are allowed to use cron jobs.

  • If /etc/cron.deny includes ALL (representing all users), and specific users are listed in /etc/cron.allow, only those users listed in the latter file are allowed to have cron jobs.

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).

Depending on how much work a cron job performs, it can noticeably increase the load on the system. If you create a user-specific cron job, try to schedule it for times when other cron jobs aren't also running. If you've authorized users to create their own cron jobs, give them times where they're authorized to run them. Audit their jobs. You can review a user's cron jobs with the crontab -u username -l command.


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.



Linux Annoyances for Geeks
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2004
Pages: 144
Authors: Michael Jang

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net