| Skip Navigation Links | |
| Exit Print View | |
|
Managing System Information, Processes, and Performance in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Managing System Information, Processes, and Performance in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. Managing System Information (Tasks)
2. Managing System Processes (Tasks)
3. Monitoring System Performance (Tasks)
4. Scheduling System Tasks (Tasks)
Ways to Automatically Executing System Tasks
For Scheduling Repetitive Jobs: crontab
For Scheduling a Single Job: at
Creating and Editing crontab Files (Task Map)
Scheduling a Repetitive System Task (cron)
How the cron Daemon Handles Scheduling
Syntax of crontab File Entries
Creating and Editing crontab Files
How to Create or Edit a crontab File
How to Verify That a crontab File Exists
Controlling Access to the crontab Command
How to Deny crontab Command Access
Scheduling Tasks by Using the at Command
Using the at Command (Task Map)
Scheduling a Single System Task (at)
Controlling Access to the at Command
How to Deny Access to the at Command
How to Verify That at Command Access Is Denied
5. Managing the System Console, Terminal Devices, and Power Services (Tasks)
This section includes tasks for scheduling system tasks by using crontab files.
|
The following sections describe how to create, edit, display, and remove crontab files, as well as how to control access to them.
The cron daemon schedules system tasks according to commands found within each crontab file. A crontab file consists of commands, one command 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 (1) 15 3 * * 0 /usr/lib/fs/nfs/nfsfind (2) 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 (3) 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean (4)
The following describes the output for each of these command lines:
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.
x86 only - The /usr/sbin/rtc script can only be run on an x86 based system.
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 4-2 Default crontab Files
|
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.
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.
The cron daemon performs the following tasks at startup:
Checks for new crontab files.
Reads the execution times that are listed within the files.
Submits the commands for execution at the proper times.
Listens for notifications from the crontab commands regarding updated crontab files.
In much the same way, the cron daemon controls the scheduling of at files. These files are stored in the /var/spool/cron/atjobs directory. The cron daemon also listens for notifications from the crontab commands regarding submitted at jobs.
A crontab file consists of commands, one command per line, that execute automatically at the time specified by the first five fields of each command line. These five fields, described in the following table, are separated by spaces.
Table 4-3 Acceptable Values for crontab Time Fields
|
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 days 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. The crontab file does not recognize extra carriage returns. For more detailed information about crontab entries and command options, refer to the crontab(1) man page.
The simplest way to create a crontab file is to use the 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. 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 root privileges.
Before You Begin
If you are creating or editing a crontab file that belongs to root or another user, you must assume the root role. See How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
You do not need to assume the root role to edit your own crontab file.
# crontab -e [username]
where username specifies the name of the user's account for which you want to create or edit a crontab file. You can create your own crontab file without superuser privileges, but you must have superuser privileges to creating or edit a crontab file for root or another user.
Follow the syntax described in Syntax of crontab File Entries. The crontab file will be placed in the /var/spool/cron/crontabs directory.
# crontab -l [username]
Example 4-1 Creating 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. Doing so ensures that the command executes properly.
# This command helps clean up user accounts. 1 0 * * 0 rm /home/jones/*.log > /dev/null 2>&1
$ ls -l /var/spool/cron/crontabs
Verify the contents of user's crontab file by using the crontab -l command as described in How to Display a crontab File.
The crontab -l command displays the contents of a crontab file much the same way that the cat command displays the contents of other types of files. You do not have to change the directory to /var/spool/cron/crontabs directory (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.
Before You Begin
Assume the root role to display a crontab file that belongs to root or another user. See How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
You do not need to assume the root role to display your own crontab file.
# crontab -l [username]
where username specifies the name of the user's account for which you want to display a crontab file. Displaying another user's crontab file 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 would be overwritten with an empty file. |
Example 4-2 Displaying a crontab File
This example shows how to use the crontab -l command to display the contents of the user's default crontab file.
$ crontab -l 13 13 * * * chmod g+w /home1/documents/*.book > /dev/null 2>&1
Example 4-3 Displaying the Default root crontab file.
This example shows how to display the default root crontab file.
$ 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. # # 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___
Example 4-4 Displaying the crontab File of Another User
This example shows how to display the crontab file that belongs to another user.
$ su Password: # crontab -l jones 13 13 * * * cp /home/jones/work_files /usr/backup/. > /dev/null 2>&1
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, the crontab -r command removes your own crontab file.
You do not have to change the directory to /var/spool/cron/crontabs (where crontab files are located) to use this command.
Before You Begin
Assume the root role to remove a crontab file that belongs to root or another user. Roles contain authorizations and privileged commands. See How to Use Your Assigned Administrative Rights in Oracle Solaris 11.1 Administration: Security Services.
You do not need to assume the root role to remove your own crontab file.
# crontab -r [username]
where username specifies the name of the user's account for which you want to remove a crontab file. Removing crontab files for another user 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 would be overwritten with an empty file. |
# ls /var/spool/cron/crontabs
Example 4-5 Removing a crontab File
The following example shows how user smith uses the crontab -r command to remove his own crontab file.
$ ls /var/spool/cron/crontabs adm jones root smith sys uucp $ crontab -r $ ls /var/spool/cron/crontabs adm jones root sys uucp
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 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 user name per line.
These access control files work together as follows:
If cron.allow exists, only the users who are 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 who are 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, which is 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 Oracle Solaris software installation, all users (except users who are 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.
$ su - Password: #
daemon bin smtp nuucp listen nobody noaccess username1 username2 username3 . . .
# cat /etc/cron.d/cron.deny daemon bin nuucp listen nobody noaccess
If you do not add root to the file, superuser access to crontab commands will be denied.
Include users that will be allowed to use the crontab command.
root username1 username2 username3 . . .
Example 4-6 Limiting crontab Command Access to Specified Users
The following example shows a cron.deny file that prevents user names jones, temp, and visitor from accessing the crontab command.
$ cat /etc/cron.d/cron.deny daemon bin smtp nuucp listen nobody noaccess jones temp visitor
The following example shows a cron.allow file. The users root, jones, and smith are the only users who can access the crontab command.
$ cat /etc/cron.d/cron.allow root jones smith
To verify if a specific user can access the crontab command, use the crontab -l command while you are logged into the user account.
$ crontab -l
If the user can access the crontab command, and already has created a crontab file, the file is displayed. Otherwise, if the user can access the crontab command but no crontab file exists, a message similar to the following message is displayed:
crontab: can't open your crontab file
Either this user either is listed in the cron.allow file (if the file exists), or the user is not listed in the cron.deny file.
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 the cron.allow file (if the file exists), or the user is listed in the cron.deny file.
|