Solaris 10 System Administration Exam Prep: Managing System Processes

This chapter is from the book

Solaris 10 System Administration Exam Prep: CX-310-200, Part I, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Solaris 10 System Administration Exam Prep: CX-310-200, Part I, 2nd Edition

Learn More Buy

Using the Solaris Batch-Processing Facility

A way to divide processes on a busy system is to schedule jobs so that they run at different times. A large job, for example, could be scheduled to run at 2:00 a.m., when the system would normally be idle. Solaris supports two methods of batch processing: the crontab and at commands. The crontab command schedules multiple system events at regular intervals, and the at command schedules a single system event.

Configuring crontab

Objective:

Explain how to schedule the automatic recurring execution of a command.

cron is a Unix utility named after Chronos ("time"), the ancient Greek god of time. It enables you to execute commands automatically according to a schedule you define. The cron daemon schedules system events according to commands found in 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 five date and time fields that tell the cron daemon when to execute the command. The sixth field is the full pathname of the program you want to run. These fields, described in Table 5.14, are separated by spaces.

Table 5.14. The crontab File

Follow these guidelines when making entries in the crontab file:

• Use a space to separate fields.
• Use a comma to separate multiple values in any of the date or time fields.
• Use a hyphen to designate a range of values in any of the date or time fields.
• Use an asterisk as a wildcard to include all possible values in any of the date or time fields. For example, an asterisk (*) can be used in the first five fields (time fields) to mean all legal values.
• Use a comment mark (#) at the beginning of a line to indicate a comment or a blank line.
• Each command within a crontab file must consist of one line, even if it is very long, because crontab does not recognize extra carriage returns.
• There can be no blank lines in the crontab file. Although this is not documented well, and some crontab files I've seen contain blank lines, the system will generate an email to root with a message that "there is an error in your crontab file."

The following sample crontab command entry displays a reminder in the user's console window at 5:00 p.m. on the 1st and 15th of every month:

0 17 1,15 * * echo Hand in Timesheet > /dev/console

crontab files are found in the /var/spool/cron/crontabs directory. Several crontab files besides root are provided during the SunOS software installation process; they are also located in this directory. Other crontab files are named after the user accounts for which they are created, such as bill, glenda, miguel, or nicole. They also are located in the /var/spool/cron/crontabs directory. For example, a crontab file named root is supplied during software installation. Its contents include these command lines:

10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
#10 3 * * * /usr/lib/krb5/kprop_script ___slave_kdcs___

The first command line instructs the system to run /usr/sbin/logadmin at 3:10 a.m. every day of the week. The second command line orders the system to execute nfsfind on Sunday at 3:15 a.m. The third command line runs each night at 3:30 a.m. and executes the gsscred command. The fourth command is commented out. The cron daemon never exits and is started via the svc:/system/cron:default service. The /etc/cron.d/FIFO file is used as a lock file to prevent running more than one instance of cron.

Creating and Editing a crontab File

Creating an entry in the crontab file is as easy as editing a text file using your favorite editor. Use the steps described next to edit this file; otherwise, your changes are not recognized until the next time the cron daemon starts up. cron examines crontab configuration files only during its own process-initialization phase or when the crontab command is run. This reduces the overhead of checking for new or changed files at regularly scheduled intervals.

Step by Step 5.2 tells you how to create or edit a crontab file.

STEP BY STEP

5.2 Creating or Editing a crontab File

1. (Optional) To create or edit a crontab file belonging to root or another user, become superuser.
2. Create a new crontab file or edit an existing one by typing the following:

   # crontab -e

   NOTE

   crontab Default Editor The crontab command chooses the system default editor, which is ed, unless you've set the VISUAL or EDITOR variable to vi (or another editor), as follows:

   # EDITOR=vi;export EDITOR

3. Add command lines to the file, following the syntax described in Table 5.14. Because cron jobs do not inherit the users environment, such as PATH, you should specify the full pathname for commands.
4. Save the changes and exit the file. The crontab file is placed in /var/spool/cron/crontabs.
5. Verify the crontab file by typing the following:

   # crontab -l

   The system responds by listing the contents of the crontab file.

Controlling Access to crontab

You can control access to crontab by modifying two files in the /etc/cron.d directory: cron.deny and cron.allow. These files permit only specified users to perform crontab tasks such as creating, editing, displaying, and removing their own crontab files. The cron.deny and cron.allow files consist of a list of usernames, one per line. These access control files work together in the following manner:

• If cron.allow exists, only the users listed in this file can create, edit, display, and remove crontab files.
• If cron.allow doesn't exist, all users may submit crontab files, except for users listed in cron.deny.
• If neither cron.allow nor cron.deny exists, superuser privileges are required to run crontab.

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

During the Solaris software installation process, a default /etc/cron.d/cron.deny file is provided. It contains the following entries:

• daemon
• bin
• nuucp
• listen
• nobody
• noaccess

None of the users listed in the cron.deny file can access crontab commands. The system administrator can edit this file to add other users who are denied access to the crontab command. No default cron.allow file is supplied. This means that, after the Solaris software installation, all users (except the ones listed in the default cron.deny file) can access crontab. If you create a cron.allow file, only those users can access crontab commands.

Scheduling a Single System Event (at)

Objective:

Explain how to schedule an automatic one-time execution of a command using the command line.

The at command is used to schedule jobs for execution at a later time. Unlike crontab, which schedules a job to happen at regular intervals, a job submitted with at executes once, at the designated time.

To submit an at job, type at followed by the time that you would like the program to execute. You'll see the at> prompt displayed and it's here that you enter the at commands. When you are finished entering the at command, press control-d to exit the at prompt and submit the job as shown in the following example:

# at 07:45am today
at> who > /tmp/log
at> <Press Control-d>
job 912687240.a at Thu Jun 6 07:14:00

When you submit an at job, it is assigned a job identification number, which becomes its filename along with the .a extension. The file is stored in the /var/spool/cron/atjobs directory. In much the same way as it schedules crontab jobs, the cron daemon controls the scheduling of at files.

The command syntax for at is shown here:

# at [-m –l -r] <time> <date>

The at command is described in Table 5.15.

Table 5.15. at Command Syntax

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 at is /etc/cron.d/at.deny. It consists of a list of usernames, one per line. The users listed in this file cannot access at commands. The default at.deny file, created during the SunOS software installation, contains the following usernames:

• daemon
• bin
• smtp
• nuucp
• listen
• nobody
• noaccess

With superuser privileges, you can edit this file to add other usernames whose at access you want to restrict.

Checking Jobs in Queue (atq and at -l)

To check your jobs that are waiting in the at queue, use the atq command. This command displays status information about the at jobs you created. Use the atq command to verify that you have created an at job. The atq command confirms that at jobs have been submitted to the queue, as shown in the following example:

# atq

The system responds with this:

Rank  Execution Date Owner  Job           Queue  Job Name
1st   Jun  6, 08:00  root   912690000.a     a    stdin
2nd   Jun  6, 08:05  root   912690300.a     a    stdin

Another way to check an at job is to issue the at -l command. This command shows the status information on all jobs submitted by a user, as shown in this example:

# at -l

The system responds with this:

user = root    912690000.a    Thu Jun  6 08:00:00
user = root    912690300.a    Thu Jun  6 08:05:00

Removing and Verifying Removal of at Jobs

To remove the at job from the queue before it is executed, type this:

# at -r [job-id]

job-id is the identification number of the job you want to remove.

Verify that the at job has been removed by using the at -l (or atq) command to display the jobs remaining in the at queue. The job whose identification number you specified should not appear. In the following example, you'll remove an at job that was scheduled to execute at 8:00 a.m. on June 6. First, check the at queue to locate the job identification number:

# at -l

The system responds with this:

user = root    912690000.a    Thu Jun  6 08:00:00
user = root    912690300.a    Thu Jun  6 08:05:00

Next, remove the job from the at queue:

# at -r 912690000.a

Finally, verify that this job has been removed from the queue:

# at -l

The system responds with this:

# user = root    912690300.a    Thu Jun  6 08:05:00

Job Scheduler

The Solaris Management Console (SMC) includes a graphical tool to create and schedule jobs on your system. You can use the Job Scheduler Tool to

• View and modify job properties
• Delete a job
• Add a scheduled job
• Enable or disable job logging

To open the Job Scheduler, follow the steps described in the "SMC Process Tool" section to start up the SMC using the smc command.

1. In the Navigation pane of the SMC Welcome window, open the Job Scheduler by clicking on the This Computer icon, then click on the Services icon, and then click on the Scheduled Jobs icon as shown in Figure 5.10.
   

   Figure 5.10 Opening the Job Scheduler.

2. You can add jobs to the crontab by selecting Action from the top toolbar as shown in Figure 5.11.
   

   Figure 5.11 Adding a cron job.

3. Modify a cron job by double clicking on the job in the main window pane as shown in Figure 5.12.
   

   Figure 5.12 Modifiying a cron job.