This chapter describes how to schedule routine or single (one-time) system tasks by using the crontab and at commands. This chapter also explains how to control access to these commands by using the following files:cron.deny cron-allow at.deny For information on the procedures that are associated with scheduling system tasks, see the following:Creating and Editing crontab Files (Task Map) Using the at Command (Task Map) Task Description For Instructions Create or edit a crontab file. Use the crontab e command to create or edit a crontab file. How to Create or Edit a crontab File Verify that a crontab file exists. Use the ls l command to verify the contents of the /var/spool/cron/crontabs file. How to Verify That a crontab File Exists Display a crontabfile. Use the ls l command to display the crontab file. How to Display a crontab File Remove a crontab file The crontab file is set up with restrictive permissions Use the crontab -r command, rather than the rm command to remove a crontab file. How to Remove a crontab File Deny crontab access To deny users access to crontab commands, add user names to the /etc/cron.d/cron.deny file by editing this file. How to Deny crontab Command Access Limit crontab access to specified users. To allow users access to the crontab command, add user names to the /etc/cron.d/cron.allow file. How to Limit crontab Command Access to Specified Users 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 command 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.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 Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.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 the following: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 the following: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 the following: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. 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. Then, they are removed from their directory. Therefore, the at command is most useful for running simple commands or scripts that direct output into separate files for later examination. Submitting an at job involves typing 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 ran, 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 checks for at jobs at startup and listens for new jobs that are submitted. After the cron daemon executes an at job, the at job's file is removed from the atjobs directory. For more information, see the at1 man page. For step-by-step instructions on scheduling at jobs, see How to Create an at Job. 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. 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.crontab File Function adm Accounting lp Printing root General system functions and file system cleanup sys Performance data 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. 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.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 days of every month. 0 16 1,15 * * echo Timesheets Due > /dev/consoleEach 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 crontab1 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 EDITORWhen 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. If you are creating or editing a crontab file that belongs to root or another user you must become superuser or assume an equivalent role. Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security ServicesYou do not need to become superuser to edit your own crontabfile. Create a new crontab file, or edit an existing 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.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. Add command lines to the crontab file.Follow the syntax described in Syntax of crontab File Entries. The crontab file will be placed in the /var/spool/cron/crontabs directory. Verify your crontab file changes.# crontab -l [username] The following example shows how to create a crontab file for another user. # crontab -e jonesThe 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 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 output shows that crontab files exist for users jones and smith. $ 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 sysVerify 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.Become superuser or assume an equivalent role to display a crontab file that belongs to root or another user. Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.You do not need to become superuser or assume an equivalent role to display your own crontab file. Display the 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.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. 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 This example shows how to display the default root crontab file.$ suPassword: Sun Microsystems Inc. SunOS 5.10 s10_51 May 2004 # 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___ This example shows how to display the crontab file that belongs to another user.$ su Password: Sun Microsystems Inc. SunOS 5.10 s10_51 May 2004 # 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.Become superuser or assume an equivalent role to remove a crontab file that belongs to root or another user. Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.You do not need to become superuser or assume an equivalent role to remove your own crontab file. Remove the 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.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. Verify that the crontab file has been removed.# ls /var/spool/cron/crontabs 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 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 noaccessNone 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 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. &rolestep.sgm;Edit the /etc/cron.d/cron.deny file and add user names, one user per line. Include users who will be denied access to the crontab commands.daemon bin smtp nuucp listen nobody noaccess username1 username2 username3 . . . Verify that the /etc/cron.d/cron.deny file contains the new entries.# cat /etc/cron.d/cron.deny daemon bin nuucp listen nobody noaccess &rolestep.sgm;Create the /etc/cron.d/cron.allow file. Add 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. Add the user names, one user name per line. Include users that will be allowed to use the crontab command.root username1 username2 username3 . . . 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 visitorThe following example shows a cron.allow file. The users root, jones, lp, and smith are the only users who can access the crontab command. $ cat /etc/cron.d/cron.allow root jones lp 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 -lIf 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 fileEither 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. Task Description For Instructions Create an at job. Use the atcommand to do the following:Start the at utility from the command line. Type the commands or scripts that you want to execute, one per line. Exit the at utility and save the job. How to Create an at Job Display the at queue. User the atq command to display the at queue. How to Display the at Queue Verify an at job. Use the atq command to confirm that at jobs that belong to a specific user have been submitted to the queue. How to Verify an at Job Display at jobs. Use the at -l[job-id to display at jobs. that have been submitted to the queue. How to Display at Jobs Remove at jobs. Use the at -r [job-id] command to remove at jobs from the queue. How to Remove at Jobs Deny access to the at command. To deny users access to the atcommand, edit the /etc/cron.d/at.deny file. How to Deny Access to the at Command The following sections describe how to use the at command to perform the following tasks:Schedule jobs (command and scripts) for execution at a later time How to display and remove these jobs 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. This designation becomes the job's file name, as well as its queue number.Submitting an at job file involves these steps:Invoking the at utility and specifying a command execution time. Typing a command or script to execute later.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 2004 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 user name per line. The users who are listed in this file cannot access at commands. The at.deny file, which is created during SunOS software installation, contains the following user names: daemon bin smtp nuucp listen nobody noaccessWith superuser privileges, you can edit the at.deny file to add other user names whose at command access you want to restrict. Start the at utility, specifying the time you want your job executed. $ at [-m] time [date] -mSends you email after the job is completed. timeSpecifies the hour that you want to schedule the job. Add am or pm if you do not specify the hours according to the 24-hour clock. Acceptable keywords are midnight, noon, and now. Minutes are optional. dateSpecifies the 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 that you want to execute, one per line. You may type 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. 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 2004She received a email 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 a file named big.file. $ at 4 am Saturday at> sort -r /usr/dict/words > /export/home/jones/big.file 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 have created. $ atq To verify that you have created an at job, use the atq command. In the following example, 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, 2004 19:30 jones 897355800.a a stdin 2nd Jul 14, 2004 23:45 jones 897543900.a a stdin 3rd Jul 17, 2004 04:00 jones 897732000.a a stdin 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. The following example shows output from the at -l command, which provides information on the status of all jobs submitted by a user.$ 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 2004The following example shows the output that is displayed when a single job is specified with the at -l command.$ at -l 897732000.a 897732000.a Tue Jul 17 04:00:00 2004 Become superuser or assume an equivalent role to remove an at job that belongs to root or another user. Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.You do not need to become superuser or assume an equivalent role to remove your own at job. 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] 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 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 &rolestep.sgm;Edit the /etc/cron.d/at.deny file and add the names of users, one user name per line, that will be prevented from using the at commands. daemon bin smtp nuucp listen nobody noaccess username1 username2 username3 . . . 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 To verify that a username was added correctly to the /etc/cron.d/at.deny file, use the at -l command while logged in as the user. If the user smith 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 command access is allowed, then the at -l command returns nothing.