Scheduling Jobs Using Cron, and Anacron

find
df
chkconfig
crontab
mailq

The cron facility
* There is no command named cron, crond is the daemon, crontab is the utility.

• allows users or admins to schedule commands or scripts
• similar to Windows' Task Manager
  
• allows the user (typically the administrator) to automate routine tasks

• the crond is started at boot time
• crond checks its configuration file once a minute 
• determine if any jobs need to be run 
• to see if its configuration files has been modified
• if so, they are re-loaded
  

$ chkconfig --list|grep cron
crond    0:off 1:off 2:on 3:on 4:on 5:on 6:off
anacron  0:off 1:off 2:off 3:off 4:off 5:off 6:off

Or use the grep utility to search for the start-up symbolic links in /etc/rc.d run-level directories

$ find /etc/rc.d -type l | grep cron
/etc/rc.d/rc0.d/K60crond
/etc/rc.d/rc0.d/K05anacron
/etc/rc.d/rc1.d/K60crond
/etc/rc.d/rc1.d/K05anacron
/etc/rc.d/rc2.d/S90crond
/etc/rc.d/rc2.d/S95anacron
/etc/rc.d/rc3.d/S90crond
/etc/rc.d/rc3.d/S95anacron
/etc/rc.d/rc4.d/S90crond
/etc/rc.d/rc4.d/S95anacron
/etc/rc.d/rc5.d/S90crond
/etc/rc.d/rc5.d/S95anacron
/etc/rc.d/rc6.d/K60crond
/etc/rc.d/rc6.d/K05anacron

Is the cron process running?

$ ps -ef|grep cron
root    1037   1  0 May08 ?   00:00:00 crond

Maintaining cron via the crontab command

• crontab allows you to edit or list the crontab configuration files
  
• lines in the cron file have a specific format
• each line specifies a command to run and what exact time to run it

# ls -l /var/spool/cron
total 2
-rw------- 1 root  sysadmin 284 Mar 15 14:53 pattyo
-rw------- 1 root  root     267 Nov 20 13:05 root

 Creating a simple cron entry using the crontab command

• first check the current time and create an example you can test

$ crontab -e
01 20 * * * df | sort -n +4

• Check to see if a file was created in /var/spool/cron
• You have to be the root user to examine the contents of the directory
  

On your Linux machine, system crontab files are configured in /etc/crontab

• run-parts is a Red Hat script
• Note the environment variables being set at the beginning of the file

$ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
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

• This file contains pointers to directories that contain scripts to be exectued on an hourly, daily, weekly, and monthly basis
• The cron.daily scripts are executed at 4:02 am every day
• The cron.weekly scripts are executed at 4:22 am every Sunday
• format: minute, hour, day of mon, mon of year, day of week
  

Anacron

• RedHat Linux systems has a second cron-like facility called anacron
• Anacron runs missed cron jobs
• System cron jobs (/etc/cron.daily, cron.weekly, cron.monthly) are scheduled to run between  4 and 5 am
• rotate logfiles, update the slocate database, update system time, cleanup temporary files, etc
  
• If the system is not up at that time, they will never run
  
• Anacron is designed for systems that are not up all the time
• our classroom machines, laptops,...
  
• config file is /etc/anacrontab

Take a look at the /etc/anacrontab file

$ cat /etc/anacrontab

1    65    cron.daily      run-parts /etc/cron.daily
7    70    cron.weekly     run-parts /etc/cron.weekly
30   75    cron.monthly    run-parts /etc/cron.monthly

• anacron checks to see if the job has executed in the last n days
  
  • where n is the period in days specified for that job
  anacron records the date the job ran in a special file so it knows when to execute the job again

Focusing on the crontab file stored in /var/spool/cron/<username> 

Even though you system cron files take care of file cleanup, we are going to look at a command to automate the cleanup of your /tmp partition as an example.

• On many UNIX machines /tmp is scrubbed at boot time
• if your system is stable, and most UNIX machines are, you don't reboot very often, thus /tmp can get quite full
• any user can write to /tmp so it tends to become full with lots of cruft that users forget exists

$ ls -l /tmp

But it could be quite tedious looking for particular files this way. The easy way to check for files beneath a specific directory is to use the find command.

The following command will do a long listing of all the files and directories under /tmp:

    $ find /tmp -exec ls -ls {} \;

The string {} is find's way of saying "Do it to each file that matches your criteria."

The string \; tells find that the -exec option is finished.

Note: You must include the backslash (\) before the semi-colon (;) or this command will NOT work.

To become more familiar with find, create a file in your /tmp directory named junk-file using touch (touch will create an empty file):

$ touch /tmp/junk-file

$ find /tmp -name 'junk*' -exec ls -l {} \;

$ find /tmp -name 'junk*' -exec rm -f {} \;
 

start searching in /tmp for any file that begins with "junk"

if match found, {} will be replaced with that file name in the exec section

then the command "rm -f <match>"  will be executed on the matched file

Now look for any file with the string "junk" in it
Note the quotes around the string 

$ find /tmp -name '*junk*' -exec ls -l {} \;

What you really want to know is which files haven't be accessed recently. This find command will list files which haven't been accessed in 7 days:

$ find /tmp -atime +7 -exec ls -l {} \;

Let's say you want to delete from /tmp any file or directory that hasn't been access in the past 7 days on a regular basis. This is the type of repetitive task that is perfect for cron.

The format used by cron contains size fields. Here is an excerpt from the crontab man 5 page describing these 6 fields (man 5 crontab):

      field          allowed values
     -----          --------------
     minute         0-59
     hour           0-23
     day of month   1-31
     month          1-12 (or names, see below)
     day of week    0-7 (0 or 7 is Sun, or use names)

  A field may be an asterisk (*), which matches all

In the following two examples, the Bourne shell script runme will execute:

• on the hour,
• at 1 AM,
• on the 10th, 11th and 12th day of the month,
• in April,
• on Saturday and Sunday.

0 1 10-12 apr sat,sun sh runme
0 1 10-12 4 6,7 sh runme

Now to create the /tmp cleanup script, first open the crontab editor:

# crontab -e

For bash
export EDITOR=vi

For tcsh or csh
setenv EDITOR vi

• save the file and exit vi.

Since the asterisks (*) matches everything, when  will this command execute?

• At 1 AM on the dot every night.

To list the contents of your crontab file:

$ crontab -l

Redirecting output

• By default, cron saves all the standard output and standard errors, and emails them to the user who owns the crontab file as a mail message.

• You may find it more useful to redirect the standard output and standard error to a log file or redirect it to mail a specific user.

• The following example is all on one line. This line will cause the standard output to be redirected to email to the postmaster.

0 5 * * * mailq -v | mail -s "Checking mail queue for stuck mail" postmaster

• If you want to be the recipient of this mail you must have an entry in either  /usr/lib/aliases, /etc/mail/aliases, or /etc/aliases (the default for RH) and you must have a valid account on the machine. 

• Put the following lines in your aliases file:

postmaster: your-account-name
root: your-account-name

• To test this, select a time a few minutes after the current time, use the date command, and modify your crontab entry accordingly. 

• See if you get the mail. 

• You can also test your command syntax by typing it is at the command line (without the first 5 fields in cron)
• the mailq command prints the messages in the system mail queue
  

$ mailq -v | mail -s "Checking mail queue for stuck mail" postmaster

Redirecting output...

• To redirect the standard output and the standard error to a log file, say /var/log/tmp.log

• use the following line in your crontabl file

0 5 * * * find /tmp -atime +7 -exec ls -l {} \; >>/var/log/tmp.log 2>&1

• the two greater than signs will not overwrite previous output
• 2 is the file descriptor for standard error
• 1 is the file descriptor for standard output
• this command instructs the shell to put the stderr in the same location that stdout is going
  

0 5 * * * find /tmp -atime +7 -exec ls -l {} \; >/dev/null 2>&1

• Note: /dev/null is basically the trash can or bit bucket.
  

A short bit on file descriptors

Almost all I/O operations in Unix are done through file descriptors which are passed the basic read / write system calls.

• A file descriptor is simply an integer representing a file opened by a process
• by convention, processes are created with three files already open: stdin (3), stdout (1), and stderr (2).
• There is a limit to the number of files that can be open by a process.
• This is a kernel parameter that can be modified.

Some redirction examples

To redirect the standard output to mail and the standard error to the log file:

0 5 * * * (find /tmp -atime +7 -exec ls -l {} \; \
   | mail -s "Older Files" pattyo) >> /tmp/errs.log 2>&1

To redirect standard error and standard out to mail:

0 5 * * * find /tmp -atime +7 -exec ls -l {} \; \
   2>&1 | mail -s "Older Files" pattyo

Finally, the best or most all-inclusive yet!

To send an email if there is an error  containing contents of log file which includes both standard error and standard out :

0 5 * * * (find /tmp -atime +7 -exec ls -l {} \; \
   || mail -s "Older Files Output" pattyo \
   < /tmp/errs.log) >> /tmp/errs.log 2>&1

Why does the second command redirect both stdout and stderr to a file but the first one only redirects stdout?

$ cat food 2>&1 > file
$ cat food > file 2>&1

• The shell sees 2>&1 first which it interprets as "make stderr go to the same place as the stdout ".
• There is no effect because both stderr and stdout are going to the terminal (since they have not been directed otherwise).
• Then the > file  redirects stdout to a file. But stderr is still going to the terminal.

Example 2:

• The shell sees > file  first which redirects stdout to file. 
• Next 2>&1 sends stderr to the same place stdout is going which is to file.

Passing output through the pipe behaves differently:

$ cat food  | mail pattyo 2>&1
$ cat food  2>&1 | mail pattyo

• The first example shows nothing in the body of the email because only stdout goes through the pipe since you didn't instruct it otherwise. 
• Stderr from cat still goes to the screen.

• The second example shows the stderr in the body of the email because you instructed the shell to send stderr to the same place that stdout was going (to the screen) then they both went through the pipe instead of to the screen.

If you can follow this you're amzing! Basically, the order of the redirectors matters.

Redirection with tee

There is one other interesting thing you can do with redirection.

• Pipe standard output as well as saving a copy of it. For example:

$ who | sort | tee who.sort | lpr

Back to CRON

• To delete the files and not just list them. 
• This command would have to be run as root so you would typically  su - root then type crontab -e. 
• Our final cron entry would look like this:

0 5 * * * (date; find /tmp -atime +7 -print -exec /bin/rm -f {} \; || mail -s "Older Files Removed" pattyo < /var/log/tmp_cleanup.log) >> /var/log/tmp_cleanup.log 2>&1

• Adding the date command gives your output  a time reference. 
• You will not get an email unless an error occurs. 
• The log file will contain a list of the files removed due to the -print option in the find command.