Managing Solaris OS System Processes

This chapter is from the book

Solaris 10 System Administration Essentials

Learn More Buy

This chapter is from the book

This chapter is from the book 

Solaris 10 System Administration Essentials

Learn More Buy

6.5 Scheduling Processes

From the user or system administrator's perspective, scheduling processes includes assigning priorities to the processes based on their importance and the need, executing a job at a time when the user will not be physically present at the system to manually start the job, distributing the job load over time, and executing a job repeatedly in a periodic fashion without manually having to start it each time.

Of the four tasks mentioned previously, the use of the nice and renice commands to assign priorities to the processes was described earlier in this chapter. Using these commands, you can increase the priority of a process that you want to complete faster. Similarly, if there is a long process taking most of the CPU time and it is not important to get this process done fast, you can use these commands to reduce its priority so that other process will get to run more.

For the other three tasks, use the crontab utility and the at command described below.

6.5.1 cron Utility

The cron utility is a general Unix utility named after Chronos (meaning "time"), the ancient Greek god of time. It allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are often termed as cron jobs in Solaris.

Crontab (CRON TABle) is a file that contains commands, one per line, that are read and executed by the cron daemon at the specified times. Each line or entry has six fields separated by space characters. 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 are described in Table 6.10.

Table 6.10. The crontab File

The first five fields can also use any one of the following formats:

• A comma separated list of integers, like 1,2,4 to match one of the listed values.
• A range of integers separated by a dash, like 3-5, to match the values within the range.

The following are some examples of entries in the crontab file.

Example 6.1: Reminder

0 18 1,15 * * echo "Update your virus definitions" > /dev/console

This entry displays a reminder in the user's console window at 5.00 p.m. on 1st and 15th of every month to update the virus definitions.

Example 6.2: Removal of Temporary Files

30 17     *    *     *         rm /home/user_x/tmp/*

This entry removes the temporary files from /home/user_x/tmp each day at 5:30 p.m.

The crontab files are found in the /var/spool/cron/crontabs directory. All the crontab files are named after the user they are created by or created for. For example, a crontab file named root is supplied during software installation. Its contents include the following 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 logchecker everyday at 3:10 a.m.
• The second command line orders the system to execute nfsfind on every 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.

Other crontab files are named after the user accounts for which they are created, such as puneet, scott, david, or vidya. They also are located in the /var/spool/cron/crontabs directory.

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

6.5.1.1 Creating and Editing crontab Files

You can create a crontab file by using crontab -e command. This command invokes the text editor that has been set for your system environment. The default editor for your system environment is defined in the EDITOR environment variable. If this variable has not been set, the crontab command uses the default editor, ed, but you can 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.

$ echo $EDITOR
$
$ EDITOR=vi
$ export EDITOR
               

If you are creating or editing a crontab file that belongs to root or another user, then you must become superuser or assume an equivalent role.

You do not need to become superuser to create or edit your own crontab file. The following are the steps to create a new or edit an existing crontab file:

1. Create a new crontab file, or edit an existing file.

   $ crontab -e [username]
         

The username specifies the name of the user's account for which you want to create or edit a crontab file. If you want to operate on your own crontab file then leave this option blank ($ crontab -e).

1. Add command lines to the crontab file. Follow the syntax described in Table 6.10.
2. Save the changes and exit the file. The crontab file will be placed in the /var/spool/cron/crontabs directory.
3. Verify your crontab file changes.

   # crontab -l [username]
         

   The contents of the crontab file for user <username> will be displayed.

   $ crontab -l
         

   The contents of your crontab file will be displayed.

6.5.1.2 Removing Existing crontab Files

You can use the crontab -r command to remove any existing crontab file. As noted previously, to remove a crontab file that belongs to root or another user, you must become superuser or assume an equivalent role.

# crontab -r [username]

This will remove the crontab file for user <username>, if any.

$ crontab -r

This will remove your existing crontab file, if any.

6.5.1.3 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 user names, 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, the only users who can access crontab commands are those whose names are specified in this cront.allow file.

For more information, see the crontab man page.

6.5.2 The at Command

Unlike the cron utility, which allows you to schedule a repetitive task to take place at any desired regular interval, the at command lets you specify a one-time action to take place at some desired time. For example, you might use crontab to perform a backup each morning at 4 a.m. and use the at command to remind yourself of a meeting later in the day.

6.5.2.1 Creating an at Job

To submit an at job, type at and then specify an execution time and a program to run, as shown in the following example:

# at 09:20am today
at> who > /tmp/log
at> <Press Control-d>
job   912687240.a       at    Thu    Jun  30    09:20:00

When you submit an at job, it is assigned a job identification number (912687240 in the case just presented), which becomes its filename along with the .a extension. The file is stored in the /var/spool/cron/atjobs directory.

The cron daemon controls the scheduling of at files similar to the way it does for crontab jobs.

The command syntax for at is shown here:

at [-m] <time> <date>

The at command syntax is described in Table 6.11.

Table 6.11. at Command Syntax

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.

Following is an example of creating an at job:

$ at -m 2130
  at> rm /home/jonny/*.backup
  at> <Press Control-D>

  job  897355800.a  at  Thu Jun 30  21:30:00 2009

This shows the at job that user jonny created to remove his backup files at 9:30 p.m. He used the -m option so that he would receive an email message after the job is done.

6.5.2.2 Checking Jobs in 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 you created. You can also 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

Rank        Execution Date          Owner       Job   Queue  Job Name
1st         Jun 30, 2009 09:20      root  912687240.a  a     stdin
2nd         Jun 30, 2009 21:30      jonny 897355800.a  a     stdin

Another way to check an at job is to issue the at -1 command. This command shows the status information on all jobs submitted by a user, or for a particular job whose id is specified. The command syntax is as follows:

$ at -l [job-id]

The <job-id> is the identification number of the job whose status you want to display. If no <job-id> is specified, then status information on all jobs submitted by this particular user is displayed.

Following is an example using at -l command:

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

6.5.2.3 Removing Existing at Jobs

You can use the at -r command to remove any existing at job. Once again, to remove an at job that belongs to root or another user you must become superuser or assume an equivalent role. You do not need to become superuser or assume an equivalent role to remove your own at job.

# at  -r [job-id]

This will remove the job with identification number job-id.

Verify that the at job has been removed by using the "at-1" 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, 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 using the at -r command. Finally, the user verifies that this job has been removed from the queue using the at -l command:

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

6.5.2.4 Controlling Access to at

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 user names, one per line.

The users listed in this file cannot access at commands. The default at.deny file, created during the Solaris OS software installation, contains the following user names:

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

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

For more information, see the at(1) man page.