System Administration Guide: Advanced Administration

Chapter 18 Scheduling System Tasks (Tasks)

This chapter describes how to schedule routine or single (one-time) systems tasks by using the crontab and at commands. This chapter also explains how to control access to these commands by using cron.deny, cron.allow, and at.deny files.

This is a list of the step-by-step instructions in this chapter.

Ways to Automatically Execute System Tasks

You can set up many system tasks to execute automatically. Some of these tasks should occur at regular intervals. Other tasks need to run only once, perhaps during off hours such as evenings or weekends.

This section contains overview information about two commands, crontab and at, which enable you to schedule routine tasks to execute automatically. The crontab schedules repetitive commands. The at command schedules tasks that execute once.

The following table summarizes crontab and at commands, as well as the files that enable you to control access to these commands.

Table 18–1 Command Summary: Scheduling System Tasks


Command	What It Schedules	Location of Files	Files That Control Access
`crontab`	Multiple system tasks at regular intervals	`/var/spool/cron/crontabs`	`/etc/cron.d/cron.allow` and `/etc/cron.d/cron.deny`
`at`	A single system task	`/var/spool/cron/atjobs`	`/etc/cron.d/at.deny`

You can also use the Solaris Management Console's Scheduled Jobs tool to schedule routine tasks. For information on using and starting the Solaris Management Console, see “Working With the Management Console (Tasks)” in System Administration Guide: Basic Administration.

For Scheduling Repetitive Jobs: `crontab`

You can schedule routine system administration tasks to execute daily, weekly, or monthly by using the crontab command.

Daily crontab system administration tasks might include:

Removing files more than a few days old from temporary directories
Executing accounting summary commands
Taking snapshots of the system by using the df and ps commands
Performing daily security monitoring
Running system backups

Weekly crontab system administration tasks might include:

Rebuilding the catman database for use by the man -k command
Running the fsck -n command to list any disk problems

Monthly crontab system administration tasks might include:

Listing files not used during a specific month
Producing monthly accounting reports

Additionally, users can schedule crontab commands to execute other routine system tasks, such as sending reminders and removing backup files.

For step-by-step instructions on scheduling crontab jobs, see How to Create or Edit a crontab File.

For Scheduling a Single Job: `at`

The at command allows you to schedule a job for execution at a later time. The job can consist of a single command or a script.

Similar to crontab, the at command allows you to schedule the automatic execution of routine tasks. However, unlike crontab files, at files execute their tasks once, and then are removed from their directory. Therefore, at is most useful for running simple commands or scripts that direct output into separate files for later examination.

Submitting an at job involves entering a command and following the at command syntax to specify options to schedule the time your job will be executed. For more information about submitting at jobs, see Description of the at Command.

The at command stores the command or script you entered, along with a copy of your current environment variable in the /var/spool/cron/atjobs directory. Your at job file name is given a long number that specifies its location in the at queue, followed by the .a extension, such as 793962000.a.

The cron daemon periodically executes the atrun program, usually at 15-minute intervals. Then the atrun program executes at jobs at their scheduled times. After the cron daemon executes your at job, the at job's file is removed from the atjobs directory.

For step-by-step instructions on scheduling at jobs, see How to Create an at Job.

Scheduling a Repetitive System Task (`cron`)

The following sections describe how to create, edit, display, and remove crontab files, as well as how to control access to them.

Inside a `crontab` File

The cron daemon schedules system tasks according to commands found within each crontab file. A crontab file consists of commands, one per line, that will be executed at regular intervals. The beginning of each line contains date and time information that tells the cron daemon when to execute the command.

For example, a crontab file named root is supplied during SunOS software installation. The file's contents include these command lines:

10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean

The first line runs the logadm command at 3:10 a.m. every day. The second line executes the nfsfind script every Sunday at 3:15 a.m. The third line runs a script that checks for daylight savings time (and make corrections if necessary) at 2:10 a.m. daily. If there is no RTC time zone nor an /etc/rtc_config file, this entry does nothing. The fourth line checks for (and removes) duplicate entries in the Generic Security Service table, /etc/gss/gsscred_db, at 3:30 a.m. daily.

For more information about the syntax of lines within a crontab file, see Syntax of crontab File Entries.

The crontab files are stored in the /var/spool/cron/crontabs directory. Several crontab files besides root are provided during SunOS software installation (see the following table).

Table 18–2 Default crontab Files


`crontab` File	Function
`adm`	Accounting
`lp`	Printing
`root`	General system functions and file system cleanup
`sys`	Performance collection
`uucp`	General `uucp` cleanup

Besides the default crontab files, users can create crontab files to schedule their own system tasks. Other crontab files are named after the user accounts in which they are created, such as bob, mary, smith, or jones.

To access crontab files that belong to root or other users, superuser privileges are required.

Procedures explaining how to create, edit, display, and remove crontab files are described in subsequent sections.

How the `cron` Daemon Handles Scheduling

The cron daemon manages the automatic scheduling of crontab commands. The role of the cron daemon is to check the /var/spool/cron/crontab directory for the presence of crontab files, normally every 15 minutes. The cron daemon checks for new crontab files or changes to existing ones, reads the execution times listed within the files, and submits the commands for execution at the proper times.

In much the same way, the cron daemon controls the scheduling of at files, which are stored in the /var/spool/cron/atjobs directory.

Syntax of `crontab` File Entries

A crontab file consists of commands, one per line, that execute automatically at the time specified by the first five fields at the beginning of each command line. These first five fields, described in the following table, are separated by spaces.

Table 18–3 Acceptable Values for crontab Time Fields


Time Field	Values
Minute	0-59
Hour	0-23
Day of month	1-31
Month	1-12
Day of week	0-6 (0 = Sunday)

Follow these guidelines for using special characters in crontab time fields:

Use a space to separate each field.
Use a comma to separate multiple values.
Use a hyphen to designate a range of values.
Use an asterisk as a wildcard to include all possible values.
Use a comment mark (#) at the beginning of a line to indicate a comment or a blank line.

For example, the following crontab command entry displays a reminder in the user's console window at 4 p.m. on the first and fifteenth of every month.

0 16 1,15 * * echo Timesheets Due > /dev/console

Each command within a crontab file must consist of one line, even if that line is very long, because crontab does not recognize extra carriage returns. For more detailed information about crontab entries and command options, refer to crontab(1).

Creating and Editing `crontab` Files

The simplest way to create a crontab file is to use the crontab -e command. This command invoke the text editor set up for your system environment, which is defined by the EDITOR environment variable. If this variable has not been set, crontab uses the default editor, ed. Preferably, you should choose an editor that you know well.

The following example shows how to determine if an editor has been defined, and how to set up vi as the default.

$ which $EDITOR
$ 
$ EDITOR=vi
$ export EDITOR

When you create a crontab file, it is automatically placed in the /var/spool/cron/crontabs directory and is given your user name. You can create or edit a crontab file for another user, or root, if you have superuser privileges.

How to Create or Edit a `crontab` File

(Optional) Become superuser to create or edit a crontab file that belongs to root or another user.

Create a new crontab file, or edit an existing one.
$ crontab -e [username]
Where username specifies the name of the user's account for which you want to create or edit a crontab file. To create or edit crontab files requires superuser privileges.

Caution –
If you accidentally type the crontab command with no option, press the interrupt character for your editor. This character allows you to quit without saving changes. If you instead saved changes and exited the file, the existing crontab file is overwritten with an empty file.

Add command lines to the file.

Follow the syntax described in Syntax of crontab File Entries. The crontab file will be placed in /var/spool/cron/crontabs.

Verify your crontab file changes.
# crontab -l [username]

Example—Creating or Editing a `crontab` File

The following example shows how to create a crontab file for another user.

# crontab -e jones

The following command entry added to a new crontab file automatically removes any log files from the user's home directory at 1:00 a.m. every Sunday morning. Because the command entry does not redirect output, redirect characters are added to the command line after *.log to make sure that the command executes properly.

# This command helps clean up user accounts.
1 0 * * 0 rm /home/jones/*.log > /dev/null 2>&1

How to Verify a `crontab` File

To verify that a crontab file exists for a user, use the ls -l command in the /var/spool/cron/crontabs directory. For example, the following display shows that crontab files exist for users smith and jones.

$ ls -l /var/spool/cron/crontabs
-rw-r--r--  1 root     sys          190 Feb 26 16:23 adm
-rw-------  1 root     staff        225 Mar  1  9:19 jones
-rw-r--r--  1 root     root        1063 Feb 26 16:23 lp
-rw-r--r--  1 root     sys          441 Feb 26 16:25 root
-rw-------  1 root     staff         60 Mar  1  9:15 smith
-rw-r--r--  1 root     sys          308 Feb 26 16:23 sys

Verify the contents of user's crontab file by using the crontab -l command as described in How to Display a crontab File.

Displaying `crontab` Files

The crontab -l command displays the contents of your crontab file much the way the cat command displays the contents of other types of files. You do not have to change directories to /var/spool/cron/crontabs (where crontab files are located) to use this command.

By default, the crontab -l command displays your own crontab file. To display crontab files that belong to other users, you must be superuser.

How to Display a `crontab` File

(Optional) Become superuser to display a crontab file that belongs to root or another user.

Display the crontab file.
$ crontab -l [username]
Where username specifies the name of the user's account for which you want to create or edit a crontab file. To create or edit crontab files requires superuser privileges.

Caution –
If you accidentally type the crontab command with no option, press the interrupt character for your editor. This character allows you to quit without saving changes. If you instead saved changes and exited the file, the existing crontab file is overwritten with an empty file.

Example—Displaying a `crontab` File

The following example shows how to use the crontab -l command to display the contents of the user's default crontab file, the default root crontab file, and the crontab file belonging to another user.

$ crontab -l
13 13 * * * chmod g+w /home1/documents/*.book > /dev/null 2>&1
$ suPassword:
# crontab -l
#ident  "@(#)root       1.19    98/07/06 SMI"   /* SVr4.0 1.1.3.1       */
#
# The root crontab should be used to perform accounting data collection.
#
# The rtc command is run to adjust the real time clock if and when
# daylight savings time changes.
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
# crontab -l jones
13 13 * * * cp /home/jones/work_files /usr/backup/. > /dev/null 2>&1

Removing `crontab` Files

By default, crontab file protections are set up so that you cannot inadvertently delete a crontab file by using the rm command. Instead, use the crontab -r command to remove crontab files.

By default, crontab -r removes your own crontab file. You must be superuser to remove crontab files that belong to superuser or other users.

You do not have to change directories to /var/spool/cron/crontabs (where crontab files are located) to use this command.

How to Remove a `crontab` File

(Optional) Become superuser to remove a crontab file that belongs to root or another user.

Remove the crontab file.
$ crontab -r [username]
Where username specifies the name of the user's account for which you want to create or edit a crontab file. To create or edit crontab files requires superuser privileges.

Caution –
If you accidentally type the crontab command with no option, press the interrupt character for your editor. This character allows you to quit without saving changes. If you instead saved changes and exited the file, the existing crontab file is overwritten with an empty file.

Verify that the crontab file is removed.
# ls /var/spool/cron/crontabs

Example—Removing a `crontab` File

The following example shows how user smith uses the crontab -r command to remove his crontab file.

$ ls /var/spool/cron/crontabs
adm     jones     lp     root    smith    sys     uucp
$ crontab -r
$ ls /var/spool/cron/crontabs
adm     jones     lp     root    sys    uucp

Controlling Access to the `crontab` Command

You can control access to the crontab command by using two files in the /etc/cron.d directory: cron.deny and cron.allow. These files permit only specified users to perform the crontab command tasks such as creating, editing, displaying, or removing their own crontab files.

The cron.deny and cron.allow files consist of a list of user names, one per line. These access control files work together as follows:

If cron.allow exists, only the users listed in this file can create, edit, display, or remove crontab files.
If cron.allow does not exist, all users can submit crontab files, except for users listed in cron.deny.
If neither cron.allow nor cron.deny exists, superuser privileges are required to run the crontab command.

Superuser privileges are required to edit or create the cron.deny and cron.allow files.

The cron.deny file, created during SunOS software installation, contains the following user names:

$ cat /etc/cron.d/cron.deny
daemon
bin
smtp
nuucp
listen
nobody
noaccess

None of the user names in the default cron.deny file can access the crontab command. You can edit this file to add other user names that will be denied access to the crontab command.

No default cron.allow file is supplied. So, after Solaris software installation, all users (except the ones listed in the default cron.deny file) can access the crontab command. If you create a cron.allow file, only these users can access the crontab command.

How to Deny `crontab` Access

Become superuser.

Edit the /etc/cron.d/cron.deny file and add user names, one per line, who will be prevented from using crontab commands.
daemon bin smtp nuucp listen nobody noaccess username1 username2 username3 . . .

Verify the /etc/cron.d/cron.deny file.
# cat /etc/cron.d/cron.deny

How to Limit `crontab` Access to Specified Users

Become superuser.

Create the /etc/cron.d/cron.allow file.

Enter the root user name into the cron.allow file.

If you do not add root to the file, superuser access to crontab commands will be denied.

Enter the user names, one per line, that will be allowed to use the crontab command.
root username1 username2 username3 . . .

Examples—Limiting `crontab` Access to Specified Users

The following example shows a cron.deny file that prevents user names visitor, jones, and temp from accessing the crontab command.

$ cat /etc/cron.d/cron.denydaemon
bin
smtp
nuucp
listen
nobody
noaccess
jones
temp
visitor

The following example shows a cron.allow file. The users smith, jones, lp, and root are the only ones who can access the crontab command.

$ cat /etc/cron.d/cron.allow
root
jones
lp
smith

How to Verify Limited `crontab` Access

To verify if a specific user can access crontab, use the crontab -l command while you are logged into the user account.

$ crontab -l

If the user can access crontab, and already has created a crontab file, the file is displayed. Otherwise, if the user can access crontab but no crontab file exists, a message such as the following is displayed:

crontab: can't open your crontab file

This user either is listed in cron.allow (if the file exists), or the user is not listed in cron.deny.

If the user cannot access the crontab command, the following message is displayed whether or not a previous crontab file exists:

crontab: you are not authorized to use cron. Sorry.

This message means that either the user is not listed in cron.allow (if the file exists), or the user is listed in cron.deny.

Scheduling a Single System Task (`at`)

The following sections describe how to use the at command to schedule jobs (commands and scripts) for execution at a later time, how to display and remove these jobs, and how to control access to the at command.

By default, users can create, display, and remove their own at job files. To access at files that belong to root or other users, you must have superuser privileges.

When you submit an at job, it is assigned a job identification number along with the .a extension, which becomes the job's file name.

Description of the `at` Command

Submitting an at job file involves:

Invoking the at utility and specifying a command execution time.
Entering a command or script to execute later.

Note –
If output from this command or script is important, be sure to direct the output to a file for later examination.

For example, the following at job removes core files from the user account smith near midnight on the last day of July.

$ at 11:45pm July 31
at> rm /home/smith/*core*
at> Press Control-d
commands will be executed using /bin/csh
job 933486300.a at Tue Jul 31 23:45:00 2001

Controlling access to the `at` Command

You can set up a file to control access to the at command, permitting only specified users to create, remove, or display queue information about their at jobs. The file that controls access to the at command, /etc/cron.d/at.deny, consists of a list of user names, one per line. The users listed in this file cannot access at commands.

The at.deny file, created during SunOS software installation, contains the following user names:

daemon
bin
smtp
nuucp
listen
nobody
noaccess

With superuser privileges, you can edit the at.deny file to add other user names whose at access you want to restrict.

How to Create an `at` Job

Start the at utility, specifying the time you want your job executed.

$ at [-m] time [date]

`-m`	Sends you email after the job is completed.
`time`	Hour that you want to schedule the job. Add `am` or `pm` if you do not specify the hours according to a 24-hour clock. Acceptable keywords are `midnight`, `noon`, and `now`. Minutes are optional.
`date`	First three or more letters of a month, a day of the week, or the keywords `today` or `tomorrow`.

At the at prompt, type the commands or scripts you want to execute, one per line.

You may enter more than one command by pressing Return at the end of each line.

Exit the at utility and save the at job by pressing Control-D.

Your at job is assigned a queue number, which is also the job's file name. This number is displayed when you exit the at utility.

Examples—Creating an `at` Job

The following example shows the at job that user jones created to remove her backup files at 7:30 p.m. She used the -m option so that she would receive an email message after her job completed.

$ at -m 1930
at> rm /home/jones/*.backup
at> Press Control-D
job 897355800.a at Thu Jul  12 19:30:00 2001

She received a mail message which confirmed the execution of her at job.

Your “at” job “rm /home/jones/*.backup”
completed.

The following example shows how jones scheduled a large at job for 4:00 a.m. Saturday morning. The job output was directed to big.file.

$ at 4 am Saturday
at> sort -r /usr/dict/words > /export/home/jones/big.file

How to Display the `at` Queue

To check your jobs that are waiting in the at queue, use the atq command. This command displays status information about the at jobs that you created.

$ atq

How to Verify an `at` Job

To verify that you have created an at job, use the atq command. The atq command confirms that at jobs that belong to jones have been submitted to the queue.

$ atq
Rank	  Execution Date     Owner     Job         Queue   Job Name
  1st   Jul 12, 2001 19:30   jones  897355800.a     a     stdin
  2nd   Jul 14, 2001 23:45   jones  897543900.a     a     stdin
  3rd   Jul 17, 2001 04:00   jones  897732000.a     a     stdin

How to Display `at` Jobs

To display information about the execution times of your at jobs, use the at -l command.

$ at -l [job-id]

Where the -l job-id option identifies the identification number of the job whose status you want to display.

Example—Displaying `at` Jobs

The following example shows output from the at -l command, which provides status information on all jobs submitted by a user.

$ at -l 
897543900.a	Sat Jul 14 23:45:00 2001
897355800.a	Thu Jul 12 19:30:00 2001
897732000.a	Tue Jul 17 04:00:00 2001

The following example shows the output displayed when a single job is specified with the at -l command.

$ at -l 897732000.a
897732000.a		Tue Jul 17 04:00:00 2001

How to Remove `at` Jobs

(Optional) Become superuser to remove an at job that belongs to root or another user.

Remove the at job from the queue before the job is executed.
$ at -r [job-id]
Where the -r job-id option specifies the identification number of the job you want to remove.

Verify that the at job is removed by using the at -l (or the atq) command.

The at -l command displays the jobs remaining in the at queue. The job whose identification number you specified should not appear.
$ at -l [job-id]

Example—Removing `at` Jobs

In the following example, a user wants to remove an at job that was scheduled to execute at 4 a.m. on July 17th. First, the user displays the at queue to locate the job identification number. Next, the user removes this job from the at queue. Finally, the user verifies that this job has been removed from the queue.

$ at -l
897543900.a	Sat Jul 14 23:45:00 2001
897355800.a	Thu Jul 12 19:30:00 2001
897732000.a	Tue Jul 17 04:00:00 2001
$ at -r 897732000.a
$ at -l 897732000.a
at: 858142000.a: No such file or directory

How to Deny Access to the `at` Command

Become superuser.

Edit the /etc/cron.d/at.deny file and add the names of users, one per line, that will be prevented from using at commands.
daemon bin smtp nuucp listen nobody noaccess username1 username2 username3 . . .

Example—Denying `at` Access

The following example shows an at.deny file that has been edited so that the users smith and jones cannot access the at command.

$ cat at.deny
daemon
bin
smtp
nuucp
listen
nobody
noaccess
jones
smith

How to Verify that `at` Access Is Denied

To verify that a username was added correctly to /etc/cron.d/at.deny, use the at -l command while logged in as the user. If the user cannot access the at command, the following message is displayed.

# su smith
Password:
$ at -l
at: you are not authorized to use at.  Sorry.

Likewise, if the user tries to submit an at job, the following message is displayed:

$ at 2:30pm
at: you are not authorized to use at.  Sorry.

This message confirms that the user is listed in the at.deny file.

If at access is allowed, the at -l command returns nothing.

Chapter 18 Scheduling System Tasks (Tasks)

Ways to Automatically Execute System Tasks

For Scheduling Repetitive Jobs: crontab

For Scheduling a Single Job: at

Scheduling a Repetitive System Task (cron)

Inside a crontab File

How the cron Daemon Handles Scheduling

Syntax of crontab File Entries

Creating and Editing crontab Files

How to Create or Edit a crontab File

Example—Creating or Editing a crontab File

How to Verify a crontab File

Displaying crontab Files

How to Display a crontab File

Example—Displaying a crontab File

Removing crontab Files

How to Remove a crontab File

Example—Removing a crontab File

Controlling Access to the crontab Command

How to Deny crontab Access

How to Limit crontab Access to Specified Users

Examples—Limiting crontab Access to Specified Users

How to Verify Limited crontab Access

Scheduling a Single System Task (at)

Description of the at Command

Controlling access to the at Command

How to Create an at Job

Examples—Creating an at Job

How to Display the at Queue

How to Verify an at Job

How to Display at Jobs

Example—Displaying at Jobs

How to Remove at Jobs

Example—Removing at Jobs

How to Deny Access to the at Command

Example—Denying at Access

How to Verify that at Access Is Denied