InformIT: Red Hat Linux 7 Unleashed > Scheduling Tasks with cron and at Jobs

Scheduling Tasks with `cron` and `at` Jobs

Red Hat Linux comes with several utilities that manage the rudiments of job scheduling. at schedules a process for later execution, and cron (or crontab—it has a couple of interfaces, and different engineers use both these names) periodically launches a process. Lastly, for systems that don't stay up all the time there's anacron.

The crond daemon is started by the crond script under the /etc/rc.d/init.d directory when you boot Red Hat Linux. This daemon checks your system's /etc/crontab file and /var/spool/cron directory every minute, looking for assigned tasks at assigned times. As a system administrator, you'll schedule system tasks in /etc/crontab. This file initially contains four entries:

001 01 * * * * root run-parts /etc/cron.hourly
002 02 4 * * * root run-parts /etc/cron.daily
003 22 4 * * 0 root run-parts /etc/cron.weekly
004 42 4 1 * * root run-parts /etc/cron.monthly
005

Scripts set to run on an hourly, daily, weekly, or monthly basis will be found under the /etc directory as shown. Personal cron tasks, created by using the crontab command, are saved under the /var/spool/cron directory. Personal at jobs are saved under the /var/spool/at directory, and will have group and file ownership of the creator, like this:

-rwx------   1 bball    bball        1093 Apr 19 17:47 a0000200eb209c

The difference between crontab and at is that crontab should be used to schedule and run periodic, repetitive tasks on a regular basis, whereas at jobs are usually meant to run once at a future time.

The weakness of cron and at is that they assume the system will always be up. This isn't true for Linux laptop systems, for instance. So by default anacron is installed and set to run at boot time and when apmd resumes (see /etc/sysconfig/apm-scripts/resume for how that's done). Anacron is controlled by the /etc/anacrontab file and is installed to look at the jobs run from the /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly directories. So it looks like this:

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/usr/bin

# These entries are useful for a Red Hat Linux system.
1       5      cron.daily     run-parts /etc/cron.daily
7       10     cron.weekly    run-parts /etc/cron.weekly
30      15     cron.monthly   run-parts /etc/cron.monthly

What this does is make sure the cron.daily scripts are run once every day (and they're run 5 minutes after anacron is run). The cron.weekly scripts are run 10 minutes after anacron starts if they haven't been run in over a week and the cron.weekly scripts are run 15 minutes after anacron starts if they haven't been run in 30 days. Anacron gets help in determining when a script was last run thanks to the 0anacron script in each of the cron directories above. You'll really notice this if you're a laptop user and always had to update your slocate database by hand!

`cron` and `find`—Exploring Disk Usage

One eternal reality of system administration is that there's not enough disk space. The following sections offer a couple expedients recommended for keeping on top of what's happening with your system.

Tracking System Core Files

cron use always involves a bit of setup. Although Appendix B gives more details on cron's features and options, I'll go carefully through an example that helps track down core clutter.

You need at least one external file to start using the cron facility. Practice cron concepts by commanding this first:


   # echo "0,5,10,15,20,25,30,35,40,45,50,55 * * * * date > `tty`" >/tmp/experiment

Then specify as follows:


   # crontab /tmp/experiment

Finally, insert this code:


   # crontab -l

The last of these gives you a result that looks something like the following:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * date > /dev/ttyxx

The current time will appear every five minutes in the window from which you launched this experiment.

For a more useful example, create a /tmp/entry file with this single line:


   0 2 * * * find / -name "core*" -exec ls -l { }  \;

Next, use this command:


   # crontab /tmp/entry

The result is that each morning at 2:00, cron launches the core-searching job and emails you the results. This is quite useful because Linux creates files core under certain error conditions. These core images are often large and can easily fill up a distressing amount of space on your disk. With the preceding sequence, you'll have a report in your email inbox each morning, listing exactly the locations and sizes of a collection of files that are likely doing you no good.

Monitoring User Space

Suppose you've experimented a bit and accumulated an inventory of cron jobs to monitor the health of your system. Along with your other jobs, you want your system to tell you every Monday morning at 2:10 which 10 users have the biggest home directory trees (/home/*). First, enter this to capture all the jobs you've scheduled:


   # crontab -l >/tmp/entries

Append this line to the bottom of /tmp/entries:

001 10 2 * * 1 du -s /home/* | sort -nr | head -10
002

Make this request and cron will email the reports you seek:

# crontab /tmp/entries

`at`: Scheduling Future Events

Suppose you write an electronic weekly column on financial cycles in the material world, which you deliver by email. To simplify legal ramifications involving financial markets, you make a point of delivering it at 5:00 Friday afternoon. It's Wednesday now, you've finished your analysis, and you're almost through packing for the vacation you're starting tonight. How do you do right by your subscribers? It only takes three lines of at scripting:


   # at 17:00 Friday << COMMAND

     mail -s "This week's CYCLES report." mailing_list < analysis.already_written

   COMMAND

This schedules the mail command for later processing. You can log off from your session and your Linux host will still send the mail at 17:00 Friday, just as you instructed. In fact, you can even shut down your machine after commanding it at ..., and, as long as it's rebooted in time, your scheduled task will still be launched on the schedule you dictated.

Other Mechanisms: Expect, Perl, and More | Next Section

Previous Section

Scheduling Tasks with cron and at Jobs

cron and find—Exploring Disk Usage

Tracking System Core Files

Monitoring User Space

at: Scheduling Future Events

Scheduling Tasks with `cron` and `at` Jobs

`cron` and `find`—Exploring Disk Usage

`at`: Scheduling Future Events