This part provides instructions for managing system resources in the Solaris environment. This part contains these chapters.
Provides overview information about Solaris commands and utilities that help you manage system resources by using disk quotas, accounting programs, and cron and at commands. |
|
Chapter 56, Examining and Changing System Information (Tasks) |
Provides step-by-step instructions for examining and changing system information. |
Provides step-by-step instructions for optimizing disk space by locating unused files and large directories. |
|
Provides step-by-step instructions for setting up and administering disk quotas. |
|
Provides step-by-step instructions for scheduling routine or one-time system events using crontab and at features. |
|
Provides step-by-step instructions for setting up and maintaining system accounting. |
|
Provides reference information for system accounting software. |
This chapter contains overview information about miscellaneous features offered by UNIX software and the Solaris operating environment to help you manage system resources by using disk quotas, accounting programs, and crontab and at commands that automatically run routine commands.
This is a list of the overview information in this chapter.
Use these references to find step-by-step instructions for managing system resources.
Quotas enable system administrators to control the size of UFS file systems by limiting the amount of disk space and the number of inodes (which roughly corresponds to the number of files) that individual users can acquire. For this reason, quotas are especially useful on the file systems where user home directories reside. (As a rule, public and /tmp file systems probably wouldn't benefit as much from the establishment of quotas.)
Setting up quotas involves these general steps:
A series of commands prepares a file system to accept quotas, ensuring that quotas will be enforced each time the system is rebooted and the file system is mounted. Entries must be added to the /etc/vfstab file, and a quotas file must be created in the top-level directory of the file system.
After a quota is created for one user, it can be copied as a prototype to set up other user quotas.
Before quotas are actually turned on, another command checks for consistency by comparing the proposed quotas to the current disk usage making sure there are no conflicts.
Finally, a command turns the quotas on for one or more entire file systems.
These steps ensure that quotas are automatically activated on a file system each time it is mounted. See Chapter 58, Managing Quotas (Tasks) for specific information about these procedures.
Once they are in place, quotas can be changed to adjust the amount of disk space or number of inodes that users can consume. Additionally, quotas can be added or removed as system needs change. See "Changing and Removing Quotas" for instructions on how to change quotas, disable individual quotas, or remove quotas from file systems.
In addition, quota status can be monitored. Quota commands enable administrators to display information about quotas on a file system, or search for users who have exceeded their quotas. For procedures that describe how to use these commands, see "Checking Quotas".
Many routine system events can be set up to execute automatically. Some of these tasks should occur repetitively, 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 commands to execute automatically, avoiding peak hours or repeating commands according to a fixed schedule. crontab schedules repetitive commands, while at schedules commands that execute once.
You can schedule routine system administration commands to execute daily, weekly, or monthly by using the crontab commands.
Daily crontab system administration tasks might include:
Removing junk files more than a few days old from temporary directories
Executing accounting summary commands
Taking snapshots of the system by using df and ps commands
Performing daily security monitoring
Running system backups
Weekly crontab system administration tasks might include:
Monthly crontab system administration tasks might include:
Listing files not used that 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.
The at command allows you to schedule a job for execution at a later time. The job may consist of a single command or a script.
Like crontab, at allows you to schedule the automatic completion of routine commands. However, unlike crontab files, at files execute their commands 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, 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 "at Command Description".
The at command stores the command or script you entered, along with a copy of your current environment variables in either /usr/spool/cron/atjobs or /var/spool/cron/atjobs. As a file name, your at job file is given a long number specifying 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. atrun then executes at jobs at their scheduled times. After your at job has been executed, its file is removed from the atjobs directory.
The SunOS 5.x system accounting software is a set of programs that enables you to collect and record data about user connect time, CPU time charged to processes, and disk usage. Once this data is collected, you can generate reports and charge fees for system usage.
The accounting programs can be used for:
Monitoring system usage
Troubleshooting
Locating and correcting performance problems
Maintaining system security
After they're set up, the system accounting programs run mostly on their own.
The accounting software provides C language programs and shell scripts that organize data into summary files and reports. These programs reside in the /usr/adm/acct and /usr/lib/acct directories.
Daily accounting can help you do four types of auditing:
Connect
Process
Disk
Fee calculations
Setting up automatic accounting involves putting the accounting startup script into crontab files so they can be started automatically by cron.
The following is an overview of how accounting works.
Between system startup and shutdown, raw data about system use (such as user logins, running processes, and data storage) are collected in accounting files.
Periodically (usually once a day), the /usr/lib/acct/runacct program processes the various accounting files and produces both cumulative summary files and daily accounting reports. The daily reports are printed by the /usr/lib/acct/prdaily program.
Monthly, the administrator can process and print the cumulative summary files generated by runacct by executing the monacct program. The summary reports produced by monacct provide an efficient means for billing users on a monthly or other fiscal basis.
See Chapter 60, Managing System Accounting (Tasks), for instructions on setting up the accounting software. See Chapter 61, System Accounting (Reference), for reference information about the different accounting features.
This chapter describes tasks required to examine and change the most common system information. This is a list of the step-by-step instructions in this chapter.
Table 56-1 describes commands that enable you to display general system information.
Table 56-1 Commands for Displaying System Information
Command |
Enables You to Display a System's ... |
---|---|
showrev(1m) |
Hostname, host identification number, release, kernel architecture, application architecture, hardware provider, domain, and kernel version |
uname(1) |
Operating system name, release, and version; node name; hardware name; processor type |
Host ID number |
|
Installed memory |
|
Date and time |
To display specific system and software release information, use the showrev command.
$ showrev [-a] |
-a |
Displays all system release information available. |
The following example shows showrev command output.
$ showrev -a Hostname: pluto Hostid: 5721864d Release: 5.6 Kernel architecture: sun4cm Application architecture: sparc Hardware provider: Sun_Microsystems Domain: solar.com Kernel version: SunOS 5.6 Generic August 1997 OpenWindows version: OpenWindows Version 3.6 January 1997 No patches are installed $ |
To display system information, use the uname command.
$ uname[-a] |
-a |
Displays the operating system name as well as the system node name, operating system release, operating system version, hardware name, and processor type. |
The following example shows uname command output.
$ uname SunOS $ uname -a SunOS pluto 5.6 Generic sun4m sparc SUNW,SPARCstation-5 $ |
To display the host identification number in hexadecimal format, use the hostid command.
$ hostid |
The following example shows sample output from the hostid command.
$ hostid 7725ac42 |
To display the amount of memory installed on your system, use the prtconf command.
$ prtconf [| grep Memory] |
grep Memory |
Focuses output from this command to display memory information only. |
The following example shows sample output from the prtconf command.
# prtconf | grep Memory Memory size: 56 Megabytes |
To display the current date and time according to your system clock, use the date command.
$ date |
The following example shows sample output from the date command.
$ date Thu Mar 6 09:06:52 MST 1997 $ |
Table 56-2 shows man page references and descriptions for some commands that enable you to change general system information.
Table 56-2 Commands for Changing System Information
Command |
Enables You to Change a System's ... |
---|---|
Date and time to match those of another system |
|
Date and time to match your specifications |
Using these commands, you can set a system's date and time to synchronize with the date and time of another system, such as a server. Or you can change a system's date and time by specifying new information.
The message of the day (MOTD) facility, located in /etc/motd, enables you to send announcements or inquiries to all users of a system when they log in. Use this facility sparingly, and edit this file regularly to remove obsolete messages.
By editing the /etc/system file, you can:
To reset the date and time to synchronize with another system, use the rdate command.
# rdate other-system-name |
other-system-name |
Name of another system. |
Verify that you have reset your system's date correctly by checking your system's date and time using the date command.
The output should show a date and time that matches that of the other system.
The following example shows how to use rdate to synchronize the date and time of one system with another. In this example, the system neptune, running several hours behind, is reset to match the date and time of the server pluto .
neptune$ date Thu Mar 6 09:07:34 MST 1997 neptune$ rdate pluto Thu Mar 6 09:08:29 1997 neptune$ date Thu Mar 6 09:08:32 MST 1997 |
Enter the new date and time.
# date mmddHHMM[[cc]yy] |
mm |
Month, using two digits. |
dd |
Day of the month, using two digits. |
HH |
Hour, using two digits and a 24-hour clock. |
MM |
Minutes, using two digits. |
cc |
Century, using two digits. |
yy |
Year, using two digits. |
Verify that you have reset your system's date correctly by checking your system's date and time using the date command with no options.
The output should show a date and time that matches that of the other system.
The following example shows how to use date to manually set a system's date and time. Thu Mar 6 09:12:00 MST 1997
# date Thu Mar 6 09:10:20 MST 1997 # date 030609121997 |
Open the /etc/motd file, using the editor of your choice.
Edit the text to include the message that will be displayed as part of the user login process, including spaces, Tabs, and Returns.
Exit the file, saving your changes.
Verify the changes by displaying the contents of the /etc/motd.
$ cat /etc/motd Welcome to the UNIX Universe. Have a nice day. |
The default message of the day, provided when you install Solaris software, contains SunOS version information:
$ cat /etc/motd Sun Microsystems Inc SunOS 5.6 Generic August 1997 |
The following example shows an edited /etc/motd file that provides information about system availabilty to each user who logs in.
$ cat /etc/motd The system will be down from 7:00 a.m to 2:00 p.m.on Saturday, August 5, for upgrades and maintenance. Do not try to access the system during those hours. Thank you... |
Add the following line to the file.
set maxuprc=value |
value |
Number of processes a user can run at once. |
Exit the file, saving changes.
Verify the maxuprc value change.
# grep maxuprc /etc/system set maxuprc=100 |
Reboot the system.
The following example shows the line you would add to the /etc/system file to allow users to run 100 processes each.
set maxuprc=100 |
Add the following line to the file.
set pt_cnt=valueset npty=same_value_as_pt_cnt set sad_cnt=2_times_pt_cnt value set nautopush=same_value_as_ pt_cnt |
set pt_cnt |
Sets the number of System V ptys. |
set npty |
Sets the number of BSD ptys. |
set sadcnt |
Sets the number of STREAMS addressable devices. |
set nautopush |
Sets the number of STREAMS autopush entries and should be two times the value of sadcnt. |
Exit the file, saving changes.
Verify the pt_cnt value change.
# grep pt_cnt /etc/system set pt_cnt=256 |
Instruct the system to reconfigure upon rebooting.
$ touch /reconfigure |
Reboot the system.
The following example increases the number of ptys to 128.
set pt_cnt=128 set npty=128 set sadcnt=256 set nautopush=128 |
By default, the number of lock requests that may occur simultaneously is 512. As users log out, they lock files, including utmp. If more than 512 users are likely to log out simultaneously (within a few seconds), the number of file locks allowed must be increased.
Add the following line to the file to increase the number of lock requests (default is 512).
set tune_t_flckrec=value |
Exit the file, saving changes.
Verify the tune_t_flckrec value change.
# grep tune_t_flckrec /etc/system set tune_t_flckrec=value |
The following example increases the number of lock requests to 1024.
set tune_t_flckrec=1024 |
Add the following variables to increase shared memory segments.
set shmsys:shminfo_shmmax=value set shmsys:shminfo_shmmin=value set shmsys:shminfo_shmmni=value set shmsys:shminfo_shmseg=value set semsys:seminfo_semmap=value set semsys:seminfo_semmni=value set semsys:seminfo_semmns=value set semsys:seminfo_semmsl=value set semsys:seminfo_semmnu=value set semsys:seminfo_semume=value |
Exit the file, saving changes.
Verify the shared memory value changes.
# grep shmsys /etc/system |
The following shared memory values accommodate a system with a large amount of memory (for example, 128 MBytes) that is running a large database application.
set shmsys:shminfo_shmmax=268435456 set shmsys:shminfo_shmmin=200 set shmsys:shminfo_shmmni=200 set shmsys:shminfo_shmseg=200 set semsys:seminfo_semmap=250 set semsys:seminfo_semmni=500 set semsys:seminfo_semmns=500 set semsys:seminfo_semmsl=500 set semsys:seminfo_semmnu=500 set semsys:seminfo_semume=100 |
This chapter describes how to optimize disk space by locating unused files and large directories. This is a list of the step-by-step instructions in this chapter.
"How to Display Information About Blocks, Files, and Disk Space"
"How to Display the Size of Directories, Subdirectories, and Files"
"How to Display the User Allocation of Local UFS File System"
Use the df command and its options to report the number of free disk blocks and files. For more information, see df(1M).
Display information about how disk space is used by using the df command.
$ df [directory] [-F fstype] [-g] [-k] [-t] |
df |
With no options, lists all mounted file systems and their device names, the number of total 512-byte blocks used, and the number of files. |
directory |
Directory whose file system you want to check. The device name, blocks used, and number of files are displayed. |
-F fstype |
Displays a list of unmounted file systems, their device names, the number of 512-byte blocks used, and the number of files on file systems of type fstype. |
-g |
Displays the statvfs structure for all mounted file systems. |
-k |
Displays a list of file systems, kilobytes used, free kilobytes, percent capacity used, and mount points. |
-t |
Displays total blocks as well as blocks used for all mounted file systems. |
For remotely mounted file systems, "-1 files"is displayed instead of the number of files.
In the following example, the file systems root (/), /usr, /proc, and /tmp are on the local disk. The other file systems are mounted by NFS and do not use local disk resources.
$ df / (/dev/dsk/c0t3d0s0 ): 30374 blocks 14002 files /usr (/dev/dsk/c0t3d0s6 ): 40714 blocks 80522 files /proc (/proc ): 0 blocks 429 files /dev/fd (fd ): 0 blocks 0 files /export/home (/dev/dsk/c0t3d0s7 ): 10712 blocks 10564 files /export/root (/dev/dsk/c0t3d0s3 ): 69180 blocks 18812 files /export/swap (/dev/dsk/c0t3d0s4 ): 61804 blocks 29563 files /opt (/dev/dsk/c0t3d0s5 ): 15722 blocks 13147 files /tmp (swap ): 57104 blocks 5653 files /usr/local (mars:/usr/local ): 435040 blocks -1 files $ |
In the following example, the file system, total Kbytes, used Kbytes, available Kbytes, percent of capacity used, and mount point are displayed.
$ df -k Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t3d0s0 30991 15812 12089 57% / /dev/dsk/c0t3d0s6 185303 164946 1827 99% /usr /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd /dev/dsk/c0t3d0s7 19095 13739 3456 80% /export/home /dev/dsk/c0t3d0s3 34599 9 31140 1% /export/root /dev/dsk/c0t3d0s4 55511 24609 25352 50% /export/swap /dev/dsk/c0t3d0s5 23063 15202 5561 74% /opt swap 29564 976 28588 4% /tmp mars:/usr/local 5353093 5135591 163972 97% /usr/local $ |
The following example shows information about the same system as the previous example, but only UFS file system information is displayed.
$ df -F ufs / (/dev/dsk/c0t3d0s0 ): 30358 blocks 14002 files /usr (/dev/dsk/c0t3d0s6 ): 40714 blocks 80522 files /export/home (/dev/dsk/c0t3d0s7 ): 10712 blocks 10564 files /export/root (/dev/dsk/c0t3d0s3 ): 69180 blocks 18812 files /export/swap (/dev/dsk/c0t3d0s4 ): 61804 blocks 29563 files /opt (/dev/dsk/c0t3d0s5 ): 15722 blocks 13147 files $ |
Although /proc and /tmp are local file systems, they are not UFS file systems (/proc is a PROCFS file system, and /tmp is a TMPFS file system).
The following example shows a list of all mounted file systems, device names, total 512-byte blocks used, and number of files. The second line of each two-line entry displays the total number of blocks and files allocated for the file system.
$ df -t / (/dev/dsk/c0t3d0s0 ): 30358 blocks 14002 files total: 61982 blocks 16128 files /usr (/dev/dsk/c0t3d0s6 ): 40714 blocks 80522 files total: 370606 blocks 94080 files /proc (/proc ): 0 blocks 429 files total: 0 blocks 492 files /dev/fd (fd ): 0 blocks 0 files total: 0 blocks 26 files /export/home (/dev/dsk/c0t3d0s7 ): 10712 blocks 10564 files total: 38190 blocks 10752 files /export/root (/dev/dsk/c0t3d0s3 ): 69180 blocks 18812 files total: 69198 blocks 18816 files /export/swap (/dev/dsk/c0t3d0s4 ): 61804 blocks 29563 files total: 111022 blocks 29568 files /opt (/dev/dsk/c0t3d0s5 ): 15722 blocks 13147 files total: 46126 blocks 13440 files /tmp (swap ): 57144 blocks 5653 files total: 59096 blocks 5768 files /usr/local (mars:/usr/local ): 435008 blocks -1 files total: 10706186 blocks -1 files $ |
You can check the size of files and sort them by using the ls command. You can find files that exceed a size limit by using the find command. For more information, see ls(1) and find(1).
Change the directory to where the files you want to check are located.
Display the size of the files.
$ ls [-l] [-s] |
-l |
Displays a list of files and directories in long format, showing the sizes in bytes. |
-s |
Displays a list of the files and directories, showing the sizes in blocks. |
The following example shows that lastlog, wtmp, and wtmpx are substantially larger than the other files in the /var/adm directory.
venus% cd /var/adm venus% ls -l total 434 -r--r--r-- 1 root other 585872 Jan 28 14:53 lastlog drwxrwxr-x 2 adm adm 512 Dec 1 16:35 log -rw-r--r-- 1 root other 408 Jan 28 14:15 messages -rw-r--r-- 1 root other 177 Jan 24 16:56 messages.0 -rw-r--r-- 1 root other 177 Jan 17 16:13 messages.1 -rw-r--r-- 1 root other 0 Jan 4 04:05 messages.2 -rw-r--r-- 1 root other 562 Jan 2 13:13 messages.3 drwxrwxr-x 2 adm adm 512 Dec 1 16:35 passwd drwxrwxr-x 2 adm sys 512 Jan 28 11:38 sa -rw-rw-rw- 1 bin bin 0 Nov 26 10:56 spellhist -rw------- 1 root root 1319 Jan 28 14:58 sulog -rw-r--r-- 1 root bin 288 Jan 28 14:53 utmp -rw-r--r-- 1 root bin 2976 Jan 28 14:53 utmpx -rw-rw-r-- 1 adm adm 12168 Jan 28 14:53 wtmp -rw-rw-r-- 1 adm adm 125736 Jan 28 14:53 wtmpx |
The following example shows that lpNet uses eight blocks and lpsched and lpsched-1 use two blocks each.
% cd /var/lp/logs % ls -s total 14 2 lpsched-1 0 lpsched-4 0 requests-2 8 lpNet 2 lpsched-2 0 requests 2 lpsched 0 lpsched-3 0 requests-1 % |
Display the size of files in blocks from largest to smallest.
$ ls -s | sort -nr | more |
sort -nr |
Sorts the list of files by block size from smallest to largest. |
In the following example, wtmpx and lastlog are the largest files in the /var/adm directory.
$ cd /var/adm $ ls -s | sort -nr | more 320 wtmpx 128 lastlog 74 pacct 56 messages 30 wtmp 6 utmpx 2 utmp 2 sulog 2 sa 2 passwd 2 log 0 spellhist total 624 |
To locate and display the names of files that exceed a specified size, use the find command.
$ find directory -size +nnn |
directory |
Directory you want to search. |
--size +nnn |
Is a number of 512-byte blocks. Files that exceed the size indicated are listed. |
The following example shows how to find files with more than 400 blocks in the current working directory.
$ find . -size +400 -print ./Howto/howto.doc ./Howto/howto.doc.backup ./Howto/howtotest.doc ./Routine/routineBackupconcepts.doc ./Routine/routineIntro.doc ./Routine/routineTroublefsck.doc ./.record ./Mail/pagination ./Config/configPrintadmin.doc ./Config/configPrintsetup.doc ./Config/configMailappx.doc ./Config/configMailconcepts.doc ./snapshot.rs |
You can display the size of directories by using the du command and its options. Additionally, you can find the amount of disk space taken up by user accounts on local UFS file systems by using the quot command. For more information about these commands, see du(1M)and quot(1M).
Display the size of one or more directories, subdirectories, and files by using the du command. Sizes are displayed in 512-byte blocks.
$ du [-as] [directory ...] |
du |
Displays the size of each directory you specify, including each subdirectory beneath it. |
-a |
Displays the size of each file and subdirectory, and the total number of blocks contained in the specified directory. |
-s |
Displays only the total number of blocks contained in the specified directory. |
directory ... |
Specifies one or more directories you want to check. |
The following example displays the sizes of two directories and all the subdirectories they contain.
$ du /var/log /var/cron 4 /var/log 3250 /var/cron |
The following example displays the sizes of two directories, all of the subdirectories and files they contain, and the total number of blocks contained in each directory.
$ du -a /var/log /var/cron 0 /var/log/authlog 0 /var/log/syslog 2 /var/log/sysidconfig.log 4 /var/log 3248 /var/cron/log 3250 /var/cron |
The following example displays the total sizes of two directories.
$ du -s /var/log /var/cron 4 /var/log 3250 /var/cron |
Display users, directories, or file systems, and the number of 1024-byte blocks used.
# quot [-a] [filesystem] |
-a |
Lists all users of each mounted UFS file system and the number of 1024-byte blocks used. |
filesystem |
Is a UFS file system. Users and the number of blocks used are displayed. |
The quot command works only on local UFS file systems.
In the following example, users of the root (/) file system are displayed, then users of all mounted UFS file systems are displayed.
# quot / /dev/rdsk/c0t0d0s0: 35400 bin 14312 smtp 183 adm 49 lp 47 uucp 37 bob 28 sys 2 mary # quot -a /dev/rdsk/c0t0d0s0 (/): 35400 bin 14312 smtp 183 adm 49 lp 47 uucp 37 bob 28 sys 2 mary /dev/rdsk/c0t0d0s6 (/usr): 104276 smtp 56567 bin 2000 lp 698 uucp 1 adm /dev/rdsk/c0t0d0s7 (/export/home): 617 smtp |
Part of the job of cleaning up heavily loaded file systems involves locating and removing files that have not been used recently. You can locate unused files using the ls or find commands. For more information, see ls(1) and find(1).
Other ways to conserve disk space include emptying temporary directories such as the ones located in /var/tmp or /var/spool, and deleting core and crash dump files. For more information about these files, refer to Chapter 69, Generating and Saving System Crash Information.
List files, displaying the most recently created or changed files first, by using the ls -t command.
$ ls -t [directory] |
-t |
Sorts listings by latest time stamp first. |
directory |
Directory you want to search. |
The following example shows how to use ls -t to locate the most recent files within the /var/adm directory. sulog, messages, utmpx, wtmpx, utmp, and lastlog were created or edited most recently. This is verified using output from ls -l, which shows that these three files were created or edited in March, while the other files in /var/spool were created or edited earlier.
$ ls -t /var/adm sulog wtmpx wtmp messages.1 vold.log spellhist messages utmp sa messages.2 log aculog utmpx lastlog messages.0 messages.3 acct passwd $ ls -l /var/adm total 686 drwxr-xr-x 5 adm adm 512 Feb 13 16:20 acct -rw------- 1 uucp bin 0 Feb 13 16:04 aculog -r--r--r-- 1 root other 8456 Mar 27 10:34 lastlog drwxr-xr-x 2 adm adm 512 Feb 13 16:36 log -rw-r--r-- 1 root other 117376 Mar 27 13:11 messages -rw-r--r-- 1 root other 4620 Jan 30 08:30 messages.0 -rw-r--r-- 1 root other 11176 Jan 23 04:30 messages.1 -rw-r--r-- 1 root other 60 Jan 13 09:45 messages.2 -rw-r--r-- 1 root other 0 Jan 31 04:05 messages.3 drwxr-xr-x 2 adm adm 512 Feb 13 16:03 passwd drwxr-xr-x 2 adm sys 512 Mar 20 06:59 sa -rw-rw-rw- 1 bin bin 0 Feb 13 16:04 spellhist -rw------- 1 root root 1647 Mar 27 13:28 sulog -rw-r--r-- 1 root bin 504 Mar 27 10:34 utmp -rw-r--r-- 1 root bin 5208 Mar 27 10:34 utmpx -rw-rw-rw- 1 root root 500 Jan 11 14:40 vold.log -rw-rw-r-- 1 adm adm 14724 Mar 27 10:34 wtmp -rw-rw-r-- 1 adm adm 151404 Mar 27 10:34 wtmpx |
Become superuser.
Find files that have not been accessed for a specified number of days and list them in a file.
# find directory -type f [-atime +nnn] [-mtime +nnn] -print > filename |
directory |
Directory you want to check. Directories below this also will be checked. |
-atime +nnn |
Finds files that have not been accessed within the number of days you specify. |
-mtime +nnn |
Finds files that have not been modified within the number of days you specify. |
filename |
Remove the inactive files that you listed in the previous step.
# rm `cat filename` |
filename |
File created by this command which contains the list of inactive files. |
The following example locates regular files in /var/adm and its directories that have not been accessed in the last 60 days and saves the list of inactive files in /var/tmp/deadfiles. These files are then removed with the rm command.
# find /var/adm -type f -atime +60 -print > /var/tmp/deadfiles & # more /var/tmp/deadfiles /var/adm/log/asppp.log /var/adm/aculog /var/adm/spellhist /var/adm/wtmp /var/adm/wtmpx /var/adm/sa/sa13 /var/adm/sa/sa27 /var/adm/sa/sa11 /var/adm/sa/sa23 /var/adm/sulog /var/adm/vold.log /var/adm/messages.1 /var/adm/messages.2 /var/adm/messages.3 # rm `cat /var/tmp/deadfiles` |
Change to the /var/tmp directory.
# cd /var/tmp |
Be sure you are in the right directory before completing the following step. The next step deletes all files in the current directory.
Delete the files and subdirectories in the current directory.
# rm -r * |
Change to other directories containing temporary or obsolete subdirectories and files (for example, mail, lost+found, or quotas), and delete them by repeating Step 3 above.
The following example shows how to clear out the /var/tmp directory, and verifies that all files and subdirectories were removed.
# cd /var/tmp # ls deadfiles wxconAAAa0003r:0.0 wxconAAAa000NA:0.0 test_dir wxconAAAa0003u:0.0 wxconAAAa000cc:0.0 wxconAAAa000zs:0.0 # rm -r * # ls # |
Change the directory to where you want to start the search.
Find and remove any core files in this directory and its subdirectories.
# find . -name core -exec rm {} \; |
The following example shows how to find and remove core files from the user account belonging to jones using the find command.
# cd /home/jones # find . -name core -exec rm {} \; |
Crash dump files can be very large, so if you have enabled your system to store these files, do not retain them for longer than necessary.
Change to the directory where crash dump files are stored.
# cd /var/crash/system |
system |
System that created the crash dump files. |
Be sure you are in the right directory before completing the following step. The next step deletes all files in the current directory.
Remove the crash dump files.
# rm * |
Verify the crash dump files are removed.
# ls |
The following example shows how to remove crash dump files from the system venus, and how to verify that the crash dump files were removed.
# cd /var/crash/venus # rm * # |
This chapter describes how to set up and administer quotas for disk space and inodes. This is a list of the step-by-step instructions in this chapter.
Using quotas enable system administrators to control the size of UFS file systems by limiting the amount of disk space and the number of inodes (which roughly corresponds to the number of files) that individual users can acquire. For this reason, quotas are especially useful on the file systems where user home directories reside.
Once they are in place, quotas can be changed to adjust the amount of disk space or number of inodes that users can consume. Additionally, quotas can be added or removed as system needs change. See "Changing and Removing Quotas" for instructions on changing quotas or the amount of time that quotas can be exceeded, disabling individual quotas, or removing quotas from file systems.
In addition, quota status can be monitored. Quota commands enable administrators to display information about quotas on a file system, or search for users who have exceeded their quotas. For procedures that describe how to use these commands, see "Checking Quotas".
You can set both soft and hard limits. The system will not allow a user to exceed his or her hard limit. However, a system administrator may set a soft limit (sometimes referred to as a quota) which can be temporarily exceeded by the user. The soft limit must be less than the hard limit.
Once the user exceeds the soft limit a timer begins. While the timer is ticking, the user is allowed to operate above the soft limit but cannot exceed the hard limit. Once the user goes below the soft limit, the timer gets reset. However, if the user's usage remains above the soft limit when the timer expires, the soft limit is enforced as a hard limit. By default, the soft limit timer is seven days.
The value of the timer is shown by the timeleft field in the repquota and quota commands.
For example, let's say a user has a soft limit of 10,000 blocks and a hard limit of 12,000 blocks. If the user's block usage exceeds 10,000 blocks and the timer is also exceeded (more than seven days), the user will not be able to allocate more disk blocks on that file system until his or her usage drops below the soft limit.
There are two resources that a file system provides to the user: blocks (for data) and inodes (for files). Each file consumes one inode. File data is stored in data blocks (usually made of up 1 kilobyte blocks.)
Assuming there are no directories, it is possible for a user to exceed his or her inode quota without using any blocks by creating all empty files. It is also possible for a user to use only one inode yet exceed his or her block quota by simply creating one file large enough to consume all the data blocks in the user's quota.
You can set up quotas to limit the amount of disk space and number of inodes (roughly equivalent to the number of files) available to users. These quotas are activated automatically each time a file system is mounted. This section describes how to configure file systems for quotas, and how to set up and activate quotas.
Setting up quotas involves these general steps:
A series of commands prepares a file system to accept quotas, ensuring that quotas will be enforced each time the system is rebooted and the file system is mounted. Entries must be added to the /etc/vfstab file, and a quotas file must be created in the top-level directory of the file system.
After a quota is created for one user, it can be copied as a prototype to set up other user quotas.
Before quotas are actually turned on, another command checks for consistency by comparing the proposed quotas with the current disk usage to make sure that there are no conflicts.
Finally, a command turns the quotas on for one or more entire file systems.
These steps ensure that quotas are automatically activated on a file system each time it is mounted. For specific information about these procedures, see "Setting Up Quotas Task Map"
Table 58-1 describes the commands you use to set up disk quotas.
Table 58-1 Commands for Setting Up Quotas
Command |
Enables You To ... |
---|---|
Set the hard and soft limits on the number of inodes and disk space for each user. |
|
Examine each mounted UFS file system, comparing against information stored in the file system's disk quota file, and resolve inconsistencies. |
|
Activate the quotas for the specified file systems. |
|
Display user's quotas on mounted file systems to verify that quotas have been correctly set up. |
Before you set up quotas, you need to determine how much space and how many inodes to allocate to each user. If you want to be sure the total file system space is never exceeded, you can divide the total size of the file system between the number of users. For example, if three users share a 100-Mbyte slice and have equal disk space needs, you could allocate 33 Mbytes to each. In environments where not all users are likely to push their limits, you may want to set individual quotas so that they add up to more than the total size of the file system. For example, if three users share a 100-Mbyte slice, you could allocate 40 Mbytes to each.
When you have established a quota for one user by using the edquota command, you can use this quota as a prototype to set the same quota for other users on the same file system.
After you have configured UFS file systems for quotas and established quotas for each user, run the quotacheck command to check consistency between current disk usage and quota files before you actually turn quotas on. Also, if systems are rebooted infrequently, it is a good idea to periodically run quotacheck.
The quotas you set up with edquota are not enforced until you turn them on by using the quotaon command. If you have properly configured the quota files, quotas will be turned on automatically each time a system is rebooted and the file system is mounted.
Task |
Description |
For Instructions, Go To |
|||||
---|---|---|---|---|---|---|---|
Configure a File System for Quotas |
Edit /etc/vfstab so that quotas are activated each time the file system is mounted, and create a quotas file. | ||||||
Set Up Quotas for a User |
Use the edquota command to create disk and inode quotas for a single user account. | ||||||
| |||||||
Set Up Quotas for Multiple Users |
Optional. Use edquota to apply prototype quotas to other user accounts. | ||||||
| |||||||
Check for Consistency |
Use the quotacheck command to compare quotas to current disk usage for consistency on one or more file systems. | ||||||
| |||||||
Turn Quotas On |
Use the quotaon command to initate quotas on one or more file systems. | ||||||
|
Edit the /etc/vfstab file by using the editor of your choice. Add rq to the mount options field for each UFS file system that will have quotas.
Exit the file, saving the changes.
Change directory to the top of the file system that will have quotas.
# touch quotas |
Change permissions to read/write for root only.
# chmod 600 quotas |
The following example from /etc/vfstab shows that the /export/home directory from the system pluto is mounted as an NFS file system on the local system with quotas enabled.
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # pluto:/export/home - /export/home nfs - yes rq |
The following example line from /etc/vfstab shows that the local (UFS)/work directory is mounted with quotas enabled.
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/dsk/c0t4d0s0 /dev/rdsk/c0t4d0s0 /work ufs 3 yes rq |
Use the quota editor to create a temporary file containing one line of quota information for each mounted UFS file system that has a quotas file in its top-level directory.
# edquota username |
username |
User for whom you want to set up quotas. |
Change the number of 1-Kbyte disk blocks, both soft and hard, and the number of inodes, both soft and hard, from 0 (the default) to the quotas you specify for each file system.
Exit the editor, saving your changes.
Verify the user's quota by using the quota command.
# quota -v username |
-v |
Display's user's quota information on all mounted file systems where quotas exist. |
username |
Specifies user name to view quota limits. |
The following example shows the contents of the temporary file opened by edquota on a system where /files is the only mounted file system containing a quotas file in its top-level directory.
fs /files blocks (soft = 0, hard = 0) inodes (soft = 0, hard = 0) |
The following example shows the same line in the temporary file after quotas have been set up.
fs /files blocks (soft = 50, hard = 60) inodes (soft = 90, hard = 100) |
Use the quota editor to apply the quotas you already established for a prototype user to the additional users you specify.
# edquota -p prototype-user username ... |
prototype-user |
User name of the account for which you have set up quotas. |
username .. |
Specifies one or more user names of additional accounts. |
The following example applies the quotas established for user bob to users mary and john.
# edquota -p bob mary john |
To ensure accurate disk data, the file systems being checked should be quiescent when you run the quotacheck command manually. The quotacheck command is run automatically when a system is rebooted.
Run a consistency check on UFS file systems. See the quotacheck.
# quotacheck [ -v ] -a | filesystem |
-v |
(Optional) Identifies the disk quotas for each user on a particular file system. |
-a |
Checks all file systems with an rq entry in the /etc/vfstab file. |
filesystem |
Specifies a file system to check. |
The following example checks quotas for the /export/home file system on the /dev/rdsk/c0t0d0s7 slice. The /export/home file system is the only file system with an rq entry in the /etc/vfstab file.
# quotacheck -va *** Checking quotas for /dev/rdsk/c0t0d0s7 (/export/home) |
Turn file system quotas on by using the quotaon command.
# quotaon [-v] -a | ffilesystem ...] |
-v |
(Optional) Verbose option. |
-a |
Turns quotas on for all file systems with an rq entry in the /etc/vfstab file. |
filesystem ... |
Turns quotas on for one or more file systems that you specify. |
The following example turns quotas on for the file systems on the /dev/dsk/c0t4d0s2 and /dev/dsk/c0t3d0s2 slices.
# quotaon -v /dev/dsk/c0t4d0s2 /dev/dsk/c0t3d0s2 /dev/dsk/c0t4d0s2: quotas turned on /dev/dsk/c0t3d0s2: quotas turned on |
After you have set up and turned on disk and inode quotas, you can check for users who exceed their quotas. In addition, you can check quota information for entire file systems.
Table 58-3 describes the commands you use to check quotas.
Table 58-3 Commands for Checking Quotas
Command |
Task |
---|---|
Display user quotas and current disk use, and information about users who are exceeding their quotas. |
|
Display quotas, files, and amount of space owned for specified file systems. |
You can display the quotas and disk use for individual users on file systems on which quotas have been activated by using the quota command.
Become superuser.
Display user quotas for mounted file systems where quotas are enabled.
# quota [-v] username |
-v |
(Optional) Displays users' quotas on all mounted file systems that have quotas. |
username |
Is the login name or UID of a user's account. |
The following example shows that the user account identified by UID 301 has a quota of one Kbyte but has not used any disk space.
# quota -v 301 Disk quotas for bob (uid 301): Filesystem usage quota limit timeleft files quota limit timeleft /export/home 0 1 2 0 2 3 |
Filesystem |
Is the mount point for the file system |
usage |
Is the current block usage |
quota |
Is the soft block limit |
limit |
Is the hard block limit |
timeleft |
Is the amount of time (in days) left on the quota timer |
files |
Is the current inode usage |
quota |
Is the soft inode limit |
limit |
Is the hard inode limit |
timeleft |
Is the amount time (in days) left on the quota timer. |
Display the quotas and disk use for all users on one or more file systems by using the repquota command.
Become superuser.
Display all quotas for one or all file systems, even if there is no usage.
# repquota [-v] -a | filesystem |
-v |
(Optional) Reports on quotas for all users-even those who do not consume resources. (Verbose mode). |
-a |
Reports on all file systems. |
filesystem |
(Reports on the specified file system. |
The following example shows output from the repquota command on a system that has quotas enabled on only one file system (/export/home).
# repquota -va /dev/dsk/c0t3d0s7 (/export/home): Block limits File limits User used soft hard timeleft used soft hard timeleft #301 -- 0 1 2.0 days 0 2 3 #341 -- 57 50 60 7.0 days 2 90 100 |
Block Limits |
|
used |
Is the current block usage |
soft |
Is the soft block limit |
hard |
Is the hard block limit |
timeleft |
Is the amount of time (in days) left on the quota timer |
File Limits |
|
used |
Is the current inode usage |
soft |
Is the soft inode limit |
hard |
Is the hard inode limit |
timeleft |
Is the amount of time (in days) left on the quota timer |
You can change quotas to adjust the amount of disk space or number of inodes users can consume. You can also remove quotas for individual users or from entire file systems as needed.
Table 58-4 describes the commands you use to change or remove quotas.
Table 58-4 Commands for Changing and Removing Quotas
Command |
Task |
---|---|
Change the hard and soft limits on the number of inodes or disk space for each user. Also, change the soft quota time limit for each file system with a quota. |
|
quotaoff(1M) |
Turn off quotas for specified file systems. See the quotaoff(1M) man page for more information. |
Users can exceed the soft time limits for their quotas for one week, by default. This means that after a week of repeated violations of the soft time limits of either disk space or inode quotas, the system prevents users from using any more inodes or disk blocks.
You can change the length of time that users may exceed their disk space or inode quotas by using the edquota command.
Use the quota editor to create a temporary file containing soft time limits.
# edquota -t |
Change the time limits from 0 (the default) to the time limits you specify by numbers and the keywords month, week, day, hour, min, or sec.
Exit the editor, saving your changes.
This procedure doesn't affect current quota violators.
The following example shows the contents of the temporary file opened by edquota on a system where /export/home is the only mounted file system with quotas. The 0 (default) value means that the default time limit of one week is used.
fs /export/home blocks time limit = 0 (default), files time limit = 0 (default) |
The following example shows the same temporary file after the time limit for exceeding the blocks quota has been changed to one week, and the time limit for exceeding the number of files has been changed to ten days.
fs /export/home blocks time limit = 2 weeks, files time limit = 16 days |
Use the quota editor to open a temporary file containing one line for each mounted file system that has a quotas file in its top-level directory.
# edquota username |
username |
User name whose quota will be modified. |
Although you can specify multiple users as arguments to the edquota command, the information displayed does not show which user it belongs to, which could create some confusion.
Enter the number of 1-Kbyte disk blocks, both soft and hard, and the number of inodes, both soft and hard.
Verify that a user's quota has been correctly changed by using the quota command.
# quota -v username |
-v |
Displays user quota information on all mounted file systems with quotas enabled. |
username |
User name whose quota you want to check. |
The following example shows the contents of the temporary file opened by edquota on a system where /files is the only mounted file system containing a quotas file in its top-level directory.
fs /files blocks (soft = 0, hard = 0) inodes (soft = 0, hard = 0) |
The following example shows the same temporary file after quotas have been changed.
fs /files blocks (soft = 0, hard = 500) inodes (soft = 0, hard = 100) |
The following example shows how to verify that the hard quotas for user smith have been changed to 500 1-Kbyte blocks, and 100 inodes.
# quota -v smith Disk quotas for smith (uid 12): Filesystem usage quota limit timeleft files quota limit timeleft /files 1 0 500 1 0 100 |
Use the quota editor to create a temporary file containing one line for each mounted file system that has a quotas file in its top-level directory.
# edquota username |
username |
User name whose quota will be disabled. |
Although you can specify multiple users as arguments to the edquota command, the information displayed does not show which user it belongs with, which could create some confusion.
Change the number of 1-Kbyte disk blocks, both soft and hard, and the number of inodes, both soft and hard, to 0 (zero).
Be sure you change the values to zero. Do not delete the line from the text file.
Exit the editor, saving your changes.
Verify that you have disabled a user's quota by using the quota command.
# quota -v username |
-v |
Displays user quota information on all mounted file systems with quotas enabled. |
username |
User name (UID) whose quota you want to check. |
The following example shows the contents of the temporary file opened by edquota on a system where /files is the only mounted file system containing a quotas file in its top-level directory.
fs /files blocks (soft = 50, hard = 60) inodes (soft = 90, hard = 100) |
The following example shows the same temporary file after quotas have been disabled.
fs /files blocks (soft = 0, hard = 0) inodes (soft = 0, hard = 10) |
Turn file system quotas off.
# quotaoff [ -v ] -a | filesystem ... |
-v |
(Optional) Verbose option. |
-a |
Turns quotas off for all file systems. |
filesystem1, 2, 3 ... |
Turns quotas off for one or more file systems you specify. |
The following example turns the quotas off for the /export/home file system.
# quotaoff -v /export/home /export/home: quotas turned off |
This chapter describes how to schedule routine or one-time system events by using the crontab and at commands. It 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.
You can schedule system events to execute repetitively, at regular intervals, by using the crontab command.You can schedule a single system event for execution at a specified time by using the at command. Table 59-1 summarizes crontab and at, as well as the files that enable you to control access to these commands.
Table 59-1 Command Summary: Scheduling System Events
Command |
What It Schedules |
Location of Files |
Files That Control Access |
---|---|---|---|
crontab |
Multiple system events at regular intervals |
/usr/spool/cron/crontabs or /var/spool/cron/crontabs |
/etc/cron.d/cron.allow and /etc/cron.d/cron.deny |
at |
A single system event |
/usr/spool/cron/atjobs or /var/spool/cron/atjobs |
/etc/cron.d/at.deny |
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 events 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. Its contents include these command lines:
0 20 * * 0,4 /etc/cron.d/logchecker 5 4 * * 0 /usr/lib/newsyslog 15 3 * * * /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 |
The first command line instructs the system to run logchecker at 10 on Sundays and Thursdays nights. The second command line schedules the system to run newsyslog at 4:05 every Sunday morning. The third command line orders the system to execute nfsfind daily at 3:15 in the morning The fourth command line instructs the system to check for daylight savings time and makes corrections if necessary. If there is no RTC time zone nor an /etc/rtc_config file, this entry will do nothing.
For more information about the syntax of lines within a crontab file, see "Syntax of crontab File Entries".
The crontab files are stored in /usr/spool/cron/crontabs (or /var/spool/cron/crontabs). Several crontab files besides root are provided during SunOS software installation (see Table 59-2).
Table 59-2 Default crontab Files
crontab File |
Function |
---|---|
adm |
Accounting |
lp |
Printing |
root |
General system functions and file system cleanup |
sys |
Performance collection |
Other crontab files are named after the user accounts in which they are created, such as bob, mary, smith, or jones.
Besides the default crontab file, users can create crontab files to schedule their own system events. To access crontab files belonging to root or other users, superuser privileges are required.
Procedures explaining how to create, edit, display, and remove crontab files are described in "Commands for Scheduling System Events".
The cron daemon handles the automatic scheduling of crontab commands. Its function is to check the /usr/spool/cron/crontab directory (or the /var/spool/cron/crontab directory, depending on your system configuration) for the presence of crontab files, normally every 15 minutes. It 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 /usr/spool/cron/atjobs directory.
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 Table 59-3, are separated by spaces. They indicate when the command will be executed.
Table 59-3 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 to use 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 sample 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 it 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).
The simplest way to create a crontab file is to use the crontab -e command to invoke the text editor set up for your system environment, defined by the EDITOR environment variable. If this variable has not been set, crontab uses the default editor ed. Define your EDITOR environment to be an editor you are familiar with. The following example shows how to check to see whether 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 /usr/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.
Enter crontab command entries as described in "Syntax of crontab File Entries" on "Syntax of crontab File Entries".
Be sure that you have access to the editor of your choice.
(Optional) To create or edit a crontab file belonging to root or another user, become superuser.
Create a new crontab file, or edit an existing one.
$ crontab -e [username] |
username |
Name of another user's account, and requires root privileges to create or edit. |
If you accidentally enter the crontab command with no option, press the interrupt character for your editor. This allows you to quit without saving changes. Exiting the file and saving changes at this point would overwrite an existing crontab file with an empty file.
Add command lines to the file, following the syntax described in "Syntax of crontab File Entries".
Exit the file, saving the changes.
The crontab file will be placed in /usr/spool/cron/crontabs.
Verify the crontab file by using the crontab -l command.
# crontab -l [username] |
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 will automatically remove any log files from the user's home directory at 1 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 |
To verify that a crontab file exists for a user, use the ls -l command in the /usr/spool/cron/crontabs directory. For example, the following display shows that crontab files exist for users smith and jones.
$ ls -l /usr/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 crontab -l as described in "How to Display a crontab File" on "How to Display a crontab File".
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 /usr/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 belonging to other users, you must be superuser.
(Optional) To display a crontab file belonging to root or another user, become superuser.
Display the crontab file.
$ crontab -l [username] |
username |
Name of another user's account, and requires superuser privileges to create or edit. |
If you accidentally enter the crontab command with no option, press the interrupt character for your editor. This allows you to quit without saving changes. Exiting the file and saving changes at this point would overwrite an existing crontab file with an empty file.
The following example shows how to use crontab -l to display the contents of the default user's crontab file, the default root crontab file, and the crontab file belonging to another user.
$ crontab -l 13 13 * * * chmod g+w /usr/documents/*.book > /dev/null 2>&1 $ su Password: # crontab -l #ident "@(#)root 1.12 94/03/24 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. # 0 2 * * 0,4 /etc/cron.d/logchecker 5 4 * * 6 /usr/lib/newsyslog 15 3 * * * /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 20 * * * * [ -x /usr/lib/inet/ntpdate ] && /usr/lib/inet/ntpdate -m 224.0.1.1 >/dev/null 2>&1 # 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, crontab -r removes your own crontab file. You must be superuser to remove crontab files belonging to superuser or other users.
You do not have to change directories to /usr/spool/cron/crontabs (where crontab files are located) to use this command.
(Optional) To remove a crontab file belonging to root or another user, become superuser.
Remove the crontab file.
$ crontab -r [username] |
username |
Name of another user's account, and requires superuser privilegs to create or edit. |
If you accidentally enter the crontab command with no option, press the interrupt character for your editor. This allows you to quit without saving changes. Exiting the file and saving changes at this point would overwrite an existing crontab file with an empty file.
Verify the crontab file is removed.
# ls /usr/spool/cron/crontabs |
The following example shows how to use crontab -r to remove the default user's crontab file, as well as crontab files belonging to root and another user. ls verifies that the correct crontab files have been removed.
$ ls /usr/spool/cron/crontabs adm jones lp root smith sys $ crontab -r $ ls /usr/spool/cron/crontabs adm jones lp root sys $ su Password: # crontab -r # ls /usr/spool/cron/crontabs adm jones lp sys # crontab -r jones # ls /usr/spool/cron/crontabs adm lp sys |
You can control access to crontab by using 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, 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 like this:
If cron.allow exists, only the users listed in this file can create, edit, display, or 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 Solaris software installation, a default cron.deny file is provided:
$ cat /etc/cron.d/cron.deny daemon bin smtp nuucp listen nobody noaccess |
None of these user names can access crontab commands. You can edit this file to add other user names who will be denied access to the crontab command.
No default cron.allow file is supplied. This means that, after 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 these users can access crontab commands.
Become superuser.
Using the editor of your choice, edit the /etc/cron.d/cron.deny file to 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 |
Use the editor of your choice to create a file named /etc/cron.d/cron.allow.
Enter the user names, one per line, who will be allowed to use crontab commands.
root username1 username2 username3 . . . |
Be sure to add root to this list. If you do not, superuser access to crontab commands will be denied.
Exit the file, saving the changes.
The following example shows a cron.deny file that prevents user names visitor, jones, and temp from accessing crontab.
$ 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 smith, jones, lp, and root are the only ones who may access crontab.
$ cat /etc/cron.d/cron.allow root jones lp smith |
To verify whether or not a specific user can access crontab, use the crontab -l command while logged into the user account.
$ crontab -l |
If the user can access crontab, and already has created a crontab file, it will be displayed. Otherwise, if the user can access crontab but no crontab file exists, a message like the following will be displayed:
crontab: can't open your crontab file |
This user either is listed in cron.allow (if it exists), or is not listed in cron.deny.
If the user cannot access crontab, the following message is displayed whether or not a previous crontab file exists:
crontab: you are not authorized to use cron. Sorry. |
This means either that the user is not listed in cron.allow (if it exists), or the user is listed in cron.deny.
The following sections describe how to use at 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 at.
By default, users can create, display, and remove their own at job files. To access at files belonging 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 that becomes its file name.
Submitting an at job file includes:
Invoking the at utility, specifying a command execution time.
Entering a command or script to execute later.
If output from this command or script is important, be sure to direct it to a file for later examination.
For example, the following at job removes core files from the user account belonging to Smith near midnight on the last day of January.
$ at 11:45pm January 31 at> rm /home/smith/*core* at> Press Control-d job 852755100.a at Wed Jan 8 13:25:00 1997 |
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, /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 this file to add other user names whose at access you want to restrict.
Enter the at facility, specifying the time you want your job executed, and press Return.
$ at [-m] time [date] |
-m |
Sends you mail 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. midnight, noon, and now are acceptable keywords. 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, enter 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 its 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 at night. She used the -m option so that she would receive a mail message after her job completed.
$ at -m 1930 at> rm /home/jones/*.backup at> Press Control-d job 852777000.a at Wed Jan 8 19:30:00 1997 |
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 Saturday morning. The output of which was directed to 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 created.
$ atq |
To verify that you have created an at job, use the atq command. The atq command confirms that at jobs belonging to jones have been submitted to the queue.
$ atq Rank Execution Date Owner Job Queue Job Name 1st Jan 8, 1997 13:25 jones 852755100.a a stdin 2nd Jan 8, 1997 19:30 jones 852777000.a a stdin 3rd Jan 11, 1997 04:00 jones 858142000.a a stdin |
To display information about the execution times of your at jobs, use the at -l command.
$ at -l [job-id] |
-l job-id |
Identification number of the job whose status you want to examine. |
The following example shows output from the at -l command, used to get status information on all jobs submitted by a user.
$ at -l 852755100.a Wed Jan 8 13:25:00 1997 852777000.a Wed Jan 8 19:30:00 1997 858142000.a Sat Jan 11 04:00:00 1997 |
The following example shows output displayed when a single job is specified with the at -l command.
$ at -l 858142000.a 858142000.a Sat Jan 11 04:00:00 1996 |
(Optional) To remove an at job belonging to root or another user, become superuser.
Remove the at job from the queue before it is executed.
$ at -r [job-id] |
-r job-id |
Identification number of the job you want to remove. |
Verify the at job is removed by using the at -l (or the atq) command to display 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 noon on March 1. 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 852755100.a Wed Jan 8 13:25:00 1997 852777000.a Wed Jan 8 19:30:00 1997 858142000.a Sat Jan 11 04:00:00 1997 $ at -r 858142000.a $ at -l 858142000.a at: 858142000.a does not exist |
Users listed in the at.deny file cannot use at to schedule jobs or to check the at queue status.
The at.deny file is placed in the /etc/cron.d directory during Solaris software installation. At that time, the same users are listed in both this file and the default cron.deny file.
daemon bin smtp nuucp listen nobody noaccess |
Root permissions are required to edit this file.
Become superuser.
Using the editor of your choice, open the /etc/cron.d/at.deny file.
Add the names of users, one per line, who will be prevented from using at commands.
daemon bin smtp nuucp listen nobody noaccess username1 username2 username3 . . . |
Exit the file, saving your changes.
The following example shows an at.deny file that has been edited so that the users Smith and Jones may not access at.
$ cat at.deny daemon bin smtp nuucp listen nobody noaccess jones smith |
To verify whether or not a user's name 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 at commands, 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 confirms that the user is listed in the at.deny file.
This section contains some simple procedures for setting up and maintaining system accounting.
This is a list of the step-by-step instructions in this chapter.
You can set up system accounting to run while the system is in multiuser mode (system state 2). Generally, this involves:
Creating /etc/rc0.d/K22acct and /etc/rc2.d/S22acct.
Modifying /var/spool/cron/crontabs/adm and /var/spool/cron/crontabs/root.
Most of the accounting scripts are added to the /var/spool/cron/crontabs/adm database file. Table 60-1 describes the default accounting scripts.
Table 60-1 Default Accounting Scripts
Accounting Script ... |
Is Used To ... |
And Runs ... |
---|---|---|
ckpacct |
Check the size of the /usr/adm/pacct log file |
Periodically |
runacct |
Process connect, process, disk, and fee accounting information |
Daily |
monacct |
Generate fiscal reports and is run once per period |
On a fiscal basis |
You can change these defaults. After these entries have been added to the database and the accounting programs have been installed, accounting should run automatically.
Become superuser.
If necessary, install the SUNWaccr and SUNWaccu packages on your system by using the pkgadd or admintool command.
Install /etc/init.d/acct as the startup script for Run Level 2.
# ln /etc/init.d/acct /etc/rc2.d/S22acct |
Install /etc/init.d/acct as the stop script for Run Level 0.
# ln /etc/init.d/acct /etc/rc0.d/K22acct |
Modify the admcrontab file to start the ckpacct, runacct, and monacct programs automatically.
# EDITOR=vi; export EDITOR # crontab -e adm 0 * * * * /usr/lib/acct/ckpacct 30 2 * * * /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log 30 7 1 * * /usr/lib/acct/monacct |
Modify the root crontab file to start the dodisk program automatically.
# crontab -e 30 22 * * 4 /usr/lib/acct/dodisk |
Edit /etc/acct/holidays to include national and local holidays, by using the editor of your choice.
Reboot the system, or type
# /etc/init.d/acct start |
The following example shows how the crontab entries that run /usr/lib/acct/ckpacct, /usr/lib/acct/runacct, and /usr/lib/acct/monacct have been added to /var/spool/cron/crontabs/adm.
#ident "@(#)adm 1.5 92/07/14 SMI" /* SVr4.0 1.2 */ # # The adm crontab file should contain startup of performance # collection if the profiling and performance feature has been # installed. 0 * * * * /usr/lib/acct/ckpacct 30 2 * * * /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log 30 7 1 * * /usr/lib/acct/monacct |
The following example shows how the crontab entry that runs /usr/lib/acct/dodisk has been added to /var/spool/cron/crontabs/root.
#ident "@(#)root 1.12 94/03/24 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. # 0 2 * * 0,4 /etc/cron.d/logchecker 5 4 * * 6 /usr/lib/newsyslog 15 3 * * * /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 20 * * * * [ -x /usr/lib/inet/ntpdate ] && /usr/lib/inet/ntpdate -m 224.0.1.1 >/dev/null 2>&1 30 22 * * 4 /usr/lib/acct/dodisk |
The following example shows a sample /etc/acct/holidays file.
* @(#)holidays January 1, 1997 * * Prime/Nonprime Table for UNIX Accounting System * * Curr Prime Non-Prime * Year Start Start * 1997 0800 1800 * * only the first column (month/day) is significiant. * * month/day Company * Holiday * 1/1 New Years Day 1/20 Martin Luther King's Day 2/17 President's Day 5/26 Memorial Day 7/3 Day before Indep. Day 7/4 Indep. Day 9/1 Labor Day 11/27 Thanksgiving 11/28 Day after Thanksgiving 12/25 Christmas 12/26 Winter Break 12/29 Winter Break 12/30 Winter Break 12/31 Winter Break |
If you provide special user services on a request basis, such as restoring files or remote printing, you may want to bill users by running a utility called chargefee. chargefee records charges in the file /var/adm/fee and each time the runacct utility is executed, new entries are merged into the total accounting records.
Charge a user for special services.
# chargefee username amount |
username |
User account you want to bill. |
amount |
Number of units to bill the user. |
The following example charges the user print_customer 10 units.
# chargefee print_customer 10 |
This section describes how to maintain accounting information.
Unfortunately, the UNIX accounting system is not foolproof. Occasionally, a file will become corrupted or lost. Some of the files can simply be ignored or restored from backup. However, certain files must be fixed to maintain the integrity of the accounting system.
The wtmp files seem to cause the most problems in the day-to-day operation of the accounting system. When the date is changed and the system is in multiuser mode, a set of date change records is written into /var/adm/wtmp. The wtmpfix utility is designed to adjust the time stamps in the wtmp records when a date change is encountered. However, some combinations of date changes and reboots will slip through wtmpfix and cause acctcon to fail. For instructions on correcting wtmp problems, see "How to Fix a wtmp File".
Become superuser.
Change to the /var/adm/acct/nite directory.
Convert the binary file wtmp.MMDD into the ASCII file xwtmp.
# fwtmp wtmp.MMDD xwtmp |
MMDD |
Pair of two-digit numbers representing the month and day. |
Edit xwtmp. Delete the corrupted files, or delete all records from the beginning up to the date change.
Convert the ASCII file xwtmp to a binary file, overwriting the corrupted file.
# fwtmp -ic xwtmp wtmp.MMDD |
The integrity of /var/adm/acct/sum/tacct is important if you are charging users for system resources. Occasionally, mysterious tacct records appear with negative numbers, duplicate user IDs, or a user ID of 65535. First, check /var/adm/acct/sum/tacctprev, using prtacct to print it. If the contents look all right, patch the latest /var/adm/acct/sum/tacct.MMDD file, then recreate the /var/adm/acct/sum/tacct file. The following steps outline a simple patch procedure.
Become superuser.
Change to the /var/adm/acct/sum directory.
Convert the contents of tacct.MMDD from binary to ASCII format.
# acctmerg -v tacct.MMDD xtacct |
MMDD |
Month and day specified by two-digit numbers. |
Edit the xtacct file, removing bad records and writing duplicate records to another file.
Convert the xtacct file from ASCII format to binary.
# acctmerg -i xtacct tacct.MMDD |
MMDD |
Month and day specified by two-digit numbers. |
Merge the files tacct.prv and tacct.MMDD into the file tacct.
# acctmerg tacctprv tacct.MMDD tacct |
The runacct program can fail for a variety of reasons, the most common being a system crash, /var running out of space, or a corrupted wtmp file. If the activeMMDD file exists, check it first for error messages. If the active and lock files exist, check fd2log for any mysterious messages.
Called without arguments, runacct assumes that this is the first invocation of the day. The argument MMDD is necessary if runacct is being restarted and specifies the month and day for which runacct will rerun the accounting. The entry point for processing is based on the contents of statefile. To override statefile, include the desired state on the command line.
When running the runacct program manually, be sure to run it as user adm.
Remove the lastdate file and any lock* files, if any.
$ cd /var/adm/acct/nite $ rm lastdate lock* |
Restart the runacct program.
$ runacct MMDD [state] 2> /var/adm/acct/nite/fd2log & |
MMDD |
Month and day specified by two-digit numbers. |
state |
Specifies a state, or starting point, where runacct processing should begin. |
You can temporarily stop system accounting or disable it permanently.
Become superuser.
Modify the adm crontab file to stop the ckpacct, runacct, and monacct programs from running by commenting out the appropriate lines.
# EDITOR=vi; export EDITOR # crontab -e adm #0 * * * * /usr/lib/acct/ckpacct #30 2 * * * /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log #30 7 1 * * /usr/lib/acct/monacct |
Modify the crontab file for user root in order to stop the dodisk program from running by commenting out the appropriate line.
# crontab -e #30 22 * * 4 /usr/lib/acct/dodisk |
Stop accounting.
# /etc/init.d/acct stop |
To re-enable system accounting, remove the newly added comment symbols from the crontab files and restart accounting.
# /etc/init.d/acct start |
Become superuser.
Modify the adm crontab file and delete the entries for the ckpacct, runacct, and monacct programs.
# EDITOR=vi; export EDITOR # crontab -e adm |
Modify the root crontab file and delete the entries for the dodisk program.
# crontab -e |
Remove the startup script for Run Level 2.
# unlink /etc/rc2.d/S22acct |
Remove the stop script for Run Level 0.
# unlink /etc/rc0.d/K22acct |
Stop accounting.
# /etc/init.d/acct stop |
This is a list of reference information in this chapter.
Daily accounting can help you track four types of accounting: connect accounting, process accounting, disk accounting, and fee calculations.
Connect accounting enables you to determine the following:
The length of time a user was logged in
How the tty lines are being used
The number of reboots on your system
The frequency with which the accounting software was turned off and on
To provide this information, the system stores records of time adjustments, boot times, times the accounting software was turned off and on, changes in run levels, the creation of user processes (login processes and init processes), and the deaths of processes. These records (produced from the output of system programs such as date, init, login, ttymon, and acctwtmp) are stored in the /var/adm/wtmp file. Entries in the wtmp file may contain the following information: a user's login name, a device name, a process ID, the type of entry, and a time stamp denoting when the entry was made.
Process accounting enables you to keep track of the following data about each process run on your system:
User and group IDs of those using the process
Beginning and elapsed times of the process
CPU time for the process (user time and system time)
Amount of memory used
Commands run
The tty controlling the process
Every time a process dies, the exit program collects this data and writes it to /var/adm/pacct.
Disk accounting enables you to gather and format the following data about the files each user has on disks:
Name and ID of the user
Number of blocks used by the user's files
This data is collected by the shell script /usr/lib/acct/dodisk at intervals determined by the entry you add to the /var/spool/cron/crontabs/root file. In turn, dodisk invokes the commands acctdusg and diskusg, which gather disk usage by login.
See "How to Set Up System Accounting" for more information about setting up dodisk.
The acctdusg command gathers all the disk accounting information. Each time it is invoked, this command can process a maximum of 3000 users.
Information gathered by running dodisk is stored in the /var/adm/acct/nite/disktacct file. This information is overwritten the next time dodisk is run. Therefore, avoid running dodisk twice in the same day.
The diskusg command may overcharge for files that are written in random access fashion, which may create holes in the files. This is because diskusg does not read the indirect blocks of a file when determining its size. Rather, diskusg determines the size of a file by looking at the di_size value of the inode.
The chargefee utility stores charges for special services provided to a user, such as file restoration, in the file /var/adm/fee. Each entry in the file consists of a user's login name, user ID, and the fee. This file is checked by the runacct program every day and new entries are merged into the total accounting records. For instructions on running chargefee to bill users, see "How to Bill Users".
Here is a step-by-step summary of how daily accounting works:
When the system is switched into multiuser mode, the /usr/lib/acct/startup program is executed. The startup program executes several other programs that invoke accounting.
The acctwtmp program adds a "boot" record to /var/adm/wtmp. In this record, the system name is shown as the login name in the wtmp record. Table 61-1 summarizes how the raw accounting data is gathered and where it is stored.
Table 61-1 Raw Accounting Data
The turnacct program, invoked with the -on option, begins process accounting. Specifically, turnacct executes the accton program with the /var/adm/pacct argument.
The remove shell script "cleans up" the saved pacct and wtmp files left in the sum directory by runacct.
The login and init programs record connect sessions by writing records into /var/adm/wtmp. Any date changes (using date with an argument) are also written to /var/adm/wtmp. Reboots and shutdowns using acctwtmp are also recorded in /var/adm/wtmp.
When a process ends, the kernel writes one record per process, using acct.h format, in the /var/adm/pacct file.
Every hour, cron executes the ckpacct program to check the size of /var/adm/pacct. If the file grows past 500 blocks (default), the turnacct switch is executed. (The program moves the pacct file and creates a new one.) The advantage of having several smaller pacct files becomes apparent when trying to restart runacct if a failure occurs when processing these records.
runacct is executed by cron each night. runacct processes the accounting files: /var/adm/pacctn, /var/adm/wtmp, /var/adm/fee, and /var/adm/acct/nite/disktacct, to produce command summaries and usage summaries by login.
The /usr/lib/acct/prdaily program is executed on a daily basis by runacct to write the daily accounting information collected by runacct (in ASCII format) in /var/adm/acct/sum/rprt.MMDD.
The monacct program should be executed on a monthly basis (or at intervals determined by you, such as the end of every fiscal period). The monacct program creates a report based on data stored in the sum directory that has been updated daily by runacct. After creating the report, monacct "cleans up" the sum directory to prepare the directory's files for the new runacct data.
If the system is shut down using shutdown, the shutacct program is executed automatically. The shutacct program writes a reason record into /var/adm/wtmp and turns off process accounting.
This section describes the various reports generated by the accounting software.
The runacct shell script generates four basic reports upon each invocation. These reports cover the areas of connect accounting, usage by login on a daily basis, command usage reported by daily and monthly totals, and a report of the last time users were logged in. Table 61-2 describes the four basic reports generated.
Table 61-2 Daily Accounting Reports
This report gives information about each terminal line used. A sample daily report appears below.
Feb 27 12:25 1997 DAILY REPORT FOR mercury Page 1 from Wed Feb 26 13:21:58 1997 to Thu Feb 27 12:25:33 1997 1 system boot 1 run-level 3 1 acctg on 1 runacct 1 acctcon TOTAL DURATION IS 1384 MINUTES LINE MINUTES PERCENT # SESS # ON # OFF /dev/pts/5 0 0 0 0 0 /dev/pts/6 0 0 0 0 1 /dev/pts/7 0 0 0 0 0 console 1337 97 1 1 1 pts/3 0 0 0 0 1 pts/4 0 0 0 0 1 pts/5 3 0 2 2 3 pts/6 232 17 5 5 5 pts/7 54 4 1 1 2 pts/8 0 0 0 0 1 pts/9 0 0 0 0 1 TOTALS 1625 -- 9 9 16 |
The from and to lines specify the time period reflected in the report--the period from the time the last accounting report was generated until the time the current accounting report was generated. It is followed by a log of system reboots, shutdowns, power failure recoveries, and any other record dumped into /var/adm/wtmp by the acctwtmp program. For more information, see acct(1M).
The second part of the report is a breakdown of line utilization. The TOTAL DURATION tells how long the system was in multiuser state (accessible through the terminal lines). The columns are described in Table 61-3.
Table 61-3 Daily Report Data
During real time, you should monitor /var/adm/wtmp because it is the file from which the connect accounting is geared. If the wtmp file grows rapidly, execute acctcon -l file < /var/adm/wtmp to see which tty line is the noisiest. If interruption is occurring frequently, general system performance will be affected. Additionally, wtmp may become corrupted. To correct this, see "How to Fix a wtmp File".
The daily usage report gives a breakdown of system resource utilization by user. A sample of this type of report appears below.
Feb 27 12:25 1997 DAILY USAGE REPORT FOR mercury Page 1 LOGIN CPU (MINS) KCORE-MINS CONNECT (MINS) DISK # OF # OF # DISK FEE UID NAME PRIME NPRIME PRIME NPRIME PRIME NPRIME BLOCKS PROCS SESS SAMPLES 0 TOTAL 1 1 2017 717 785 840 660361 1067 9 7 20 0 root 1 1 1833 499 550 840 400443 408 2 1 0 1 daemon 0 0 0 0 0 0 400 0 0 1 0 2 bin 0 0 0 0 0 0 253942 0 0 1 0 3 sys 0 0 0 0 0 0 2 0 0 1 0 4 adm 0 0 46 83 0 0 104 280 0 1 0 5 uucp 0 0 74 133 0 0 1672 316 0 1 0 71 lp 0 0 0 2 0 0 3798 1 0 1 0 8198 ksm 0 0 8 0 0 0 0 6 1 0 0 52171 pjm 0 0 56 0 234 0 0 56 6 0 20 |
The data provided in the daily usage report is described in Table 61-4.
Table 61-4 Daily Usage Report Data
The daily command summary report shows the system resource use by command. With this report, you can identify the most heavily used commands and, based on how those commands use system resources, gain insight on how best to tune the system. The format of the daily and monthly reports are virtually the same; however, the daily summary reports only on the current accounting period while the monthly summary reports on the start of the fiscal period to the current date. In other words, the monthly report reflects the data accumulated since the last invocation of monacct.
These reports are sorted by TOTAL KCOREMIN, which is an arbitrary gauge but often a good one for calculating drain on a system.
A sample daily command summary appears below.
Feb 27 12:25 1997 DAILY COMMAND SUMMARY Page 1 TOTAL COMMAND SUMMARY COMMAND NUMBER TOTAL TOTAL TOTAL MEAN MEAN HOG CHARS BLOCKS NAME CMDS KCOREMIN CPU-MIN REAL-MIN SIZE-K CPU-MIN FACTOR TRNSFD READ TOTALS 1067 2730.99 2.01 1649.38 1361.41 0.00 0.00 6253571 2305 sendmail 28 1085.87 0.05 0.24 23865.20 0.00 0.19 101544 39 admintoo 3 397.68 0.12 1132.96 3443.12 0.04 0.00 680220 83 sh 166 204.78 0.31 161.13 651.80 0.00 0.00 598158 20 nroff 12 167.17 0.14 0.24 1205.55 0.01 0.59 709048 22 find 10 151.27 0.27 2.72 563.40 0.03 0.10 877971 1580 acctdusg 3 87.40 0.13 2.74 698.29 0.04 0.05 883845 203 lp 10 74.29 0.05 0.22 1397.38 0.01 0.24 136460 57 expr 20 67.48 0.02 0.06 3213.24 0.00 0.34 6380 1 mail.loc 3 65.83 0.01 0.04 11285.60 0.00 0.15 24709 15 cmdtool 1 37.65 0.02 20.13 2091.56 0.02 0.00 151296 1 uudemon. 105 37.38 0.09 0.32 435.46 0.00 0.27 62130 17 csh 6 35.17 0.05 57.28 756.30 0.01 0.00 209560 13 col 12 31.12 0.06 0.26 523.00 0.00 0.23 309932 0 ntpdate 22 27.55 0.05 11.18 599.00 0.00 0.00 22419 0 uuxqt 44 18.66 0.04 0.06 417.79 0.00 0.74 32604 3 man 12 15.11 0.03 7.05 503.67 0.00 0.00 85266 47 . . . |
The data provided, by column, in the daily command summary is described in Table 61-5.
Table 61-5 Daily Command Summary
The monthly command summary is similar to the daily command summary. The only difference is that the monthly command summary shows totals accumulated since the last invocation of monacct. A sample report appears below.
Mar 4 02:30 1997 MONTHLY TOTAL COMMAND SUMMARY Page 1 TOTAL COMMAND SUMMARY COMMAND NUMBER TOTAL TOTAL TOTAL MEAN MEAN HOG CHARS BLOCKS NAME CMDS KCOREMIN CPU-MIN REAL-MIN SIZE-K CPU-MIN FACTOR TRNSFD READ TOTALS 771 483.70 0.94 8984.09 515.12 0.00 0.00 2248299 179 sh 105 155.41 0.23 429.58 667.94 0.00 0.00 491870 1 uudemon. 85 29.39 0.07 0.29 434.28 0.00 0.23 49630 14 acctcms 5 27.21 0.04 0.04 752.41 0.01 0.90 218880 1 ntpdate 17 21.30 0.04 14.10 605.73 0.00 0.00 18192 0 dtpad 1 19.69 0.01 10.87 2072.70 0.01 0.00 46992 8 sendmail 17 16.75 0.02 0.02 859.04 0.00 0.91 1965 0 acctprc 1 14.92 0.03 0.03 552.69 0.03 0.95 115584 0 uuxqt 34 14.78 0.03 0.04 426.29 0.00 0.92 25194 0 uusched 34 10.96 0.03 0.03 363.25 0.00 0.91 25194 0 sed 40 10.15 0.03 0.09 315.50 0.00 0.36 64162 2 man 5 10.08 0.02 57.58 555.05 0.00 0.00 25773 2 getent 1 7.68 0.01 0.02 921.60 0.01 0.40 20136 0 in.rlogi 5 7.65 0.01 4331.67 611.73 0.00 0.00 87440 0 cp 37 7.28 0.03 0.05 280.08 0.00 0.50 1739 36 date 27 7.24 0.02 0.03 329.12 0.00 0.65 23443 1 ls 15 7.05 0.01 0.02 503.33 0.00 0.79 14123 0 awk 19 6.94 0.02 0.06 372.04 0.00 0.32 666 0 rm 29 6.83 0.02 0.04 301.32 0.00 0.60 2348 17 |
See "Daily Command Summary " for a description of the data.
This report gives the date when a particular login was last used. You can use this information to find unused logins and login directories that may be archived and deleted. A sample report appears below.
Feb 27 12:25 1997 LAST LOGIN Page 1 . . . 00-00-00 arimmer 00-00-00 lister 97-02-27 pjm 00-00-00 reception 00-00-00 smithey 97-02-27 ksm 00-00-00 release 00-00-00 smsc 97-02-27 root 00-00-00 resch 00-00-00 smtp |
At any time, you can examine the contents of the /var/adm/pacctn files, or any file with records in the acct.h format, by using the acctcom program. If you don't specify any files and don't provide any standard input when you run this command, acctcom reads the pacct file. Each record read by acctcom represents information about a dead process (active processes may be examined by running the ps command). The default output of acctcom provides the following information:
Command name (pound (#) sign if it was executed with superuser privileges)
User
tty name (listed as ? if unknown)
Starting time
Ending time
Real time (in seconds)
CPU time (in seconds)
Mean size (in Kbytes)
The following information can be obtained by using options to acctcom:
State of the fork/exec flag (1 for fork without exec)
System exit status
Hog factor
Total kcore minutes
CPU factor
Characters transferred
Blocks read
Table 61-6 describes the acctcom options.
Option |
Description |
---|---|
-a |
Show some average statistics about the processes selected. (The statistics are printed after the output is recorded.) |
-b
|
Read the files backward, showing latest commands first. (This has no effect if reading standard input.) |
-f |
Print the fork/exec flag and system exit status columns. (The output is an octal number.) |
-h |
Instead of mean memory size, show the hog factor, which is the fraction of total available CPU time consumed by the process during its execution. Hog factor = total_CPU_time/elapsed_time. |
-i |
Print columns containing the I/O counts in the output. |
-k |
Show total kcore minutes instead of memory size. |
-m |
Show mean core size (this is the default). |
-q |
Don't print output records, just print average statistics. |
-r |
Show CPU factor: user_time/(system_time + user_time). |
-t |
Show separate system and user CPU times. |
-v |
Exclude column headings from the output. |
-C sec |
Show only processes with total CPU time (system plus user) exceeding sec seconds. |
-e time |
Show processes existing at or before time, given in the format hr[:min[:sec]]. |
-E time |
Show processes starting at or before time, given in the format hr[:min[:sec]]. Using the same time for both -S and -E, show processes that existed at the time. |
-g group |
Show only processes belonging to group. |
-H factor |
Show only processes that exceed factor, where factor is the "hog factor" (see the -h option). |
-I chars |
Show only processes transferring more characters than the cutoff number specified by chars. |
-l line |
Show only processes belonging to the terminal /dev/line. |
-n pattern |
Show only commands matching pattern (a regular expression except that "+" means one or more occurrences). |
-o ofile |
Instead of printing the records, copy them in acct.h format to ofile. |
-O sec |
Show only processes with CPU system time exceeding sec seconds. |
-s time |
Show processes existing at or after time, given in the format hr[:min[:sec]]. |
-S time |
Show processes starting at or after time, given in the format hr[:min[:sec]]. |
-u user |
Show only processes belonging to user. |
The main daily accounting shell script, runacct, is normally invoked by cron outside of prime time hours. The runacct shell script processes connect, fee, disk, and process accounting files. It also prepares daily and cumulative summary files for use by prdaily and monacct for billing purposes.
The runacct shell script takes care not to damage files if errors occur. A series of protection mechanisms are used that attempt to recognize an error, provide intelligent diagnostics, and complete processing in such a way that runacct can be restarted with minimal intervention. It records its progress by writing descriptive messages into the file active. (Files used by runacct are assumed to be in the /var/adm/acct/nite directory, unless otherwise noted.) All diagnostic output during the execution of runacct is written into fd2log.
When runacct is invoked, it creates the files lock and lock1. These files are used to prevent simultaneous execution of runacct. The runacct program prints an error message if these files exist when it is invoked. The lastdate file contains the month and day runacct was last invoked, and is used to prevent more than one execution per day. If runacct detects an error, a message is written to the console, mail is sent to root and adm, locks may be removed, diagnostic files are saved, and execution is ended. For instructions on how to start runacct again, see "How to Restart runacct".
To allow runacct to be restartable, processing is broken down into separate re-entrant states. The file statefile is used to keep track of the last state completed. When each state is completed, statefile is updated to reflect the next state. After processing for the state is complete, statefile is read and the next state is processed. When runacct reaches the CLEANUP state, it removes the locks and ends. States are executed as shown in Table 61-7.
Table 61-7 runacct States
State |
Description |
---|---|
SETUP |
The command turnacct switch is executed to create a new pacct file. The process accounting files in /var/adm/pacctn (except for the pacct file) are moved to /var/adm/Spacctn.MMDD. The /var/adm/wtmp file is moved to /var/adm/acct/nite/wtmp.MMDD (with the current time record added on the end) and a new /var/adm/wtmp is created. closewtmp and utmp2wtmp add records to wtmp.MMDD and the new wtmp to account for users currently logged in. |
WTMPFIX |
The wtmpfix program checks the wtmp.MMDD file in the nite directory for accuracy. Because some date changes will cause acctcon to fail, wtmpfix attempts to adjust the time stamps in the wtmp file if a record of a date change appears. It also deletes any corrupted entries from the wtmp file. The fixed version of wtmp.MMDD is written to tmpwtmp. |
CONNECT |
The acctcon program is used to record connect accounting records in the file ctacct.MMDD. These records are in tacct.h format. In addition, acctcon creates the lineuse and reboots files. The reboots file records all the boot records found in the wtmp file. |
PROCESS |
The acctprc program is used to convert the process accounting files, /var/adm/Spacctn.MMDD, into total accounting records in ptacctn.MMDD. The Spacct and ptacct files are correlated by number so that if runacct fails, the Spacct files will not be processed. |
MERGE |
The MERGE program merges the process accounting records with the connect accounting records to form daytacct. |
FEES |
The MERGE program merges ASCII tacct records from the fee file into daytacct. |
DISK |
If the dodisk procedure has been run, producing the disktacct file, the DISK program merges the file into daytacct and moves disktacct to /tmp/disktacct.MMDD. |
MERGETACCT |
The MERGETACCT merges daytacct with sum/tacct, the cumulative total accounting file. Each day, daytacct is saved in sum/tacct.MMDD, so that sum/tacct can be recreated if it is corrupted or lost. |
CMS |
The acctcms program is run several times. acctcms is first run to generate the command summary using the Spacctn files and write it to sum/daycms. The acctcms program is then run to merge sum/daycms with the cumulative command summary file sum/cms. Finally, acctcms is run to produce the ASCII command summary files, nite/daycms and nite/cms, from the sum/daycms and sum/cms files, respectively. The lastlogin program is used to create the /var/adm/acct/sum/loginlog log file, the report of when each user last logged in. (If runacct is run after midnight, the dates showing the time last logged in by some users will be incorrect by one day.) |
USEREXIT |
Any installation-dependent (local) accounting program can be included at this point. runacct expects it to be called /usr/lib/acct/runacct.local. |
CLEANUP |
Cleans up temporary files, runs prdaily and saves its output in sum/rpt.MMDD, removes the locks, then exits. |
When restarting runacct in the CLEANUP state, remove the last ptacct file because it will not be complete.
The /var/adm directory structure contains the active data collection files and is owned by the adm login (currently user ID of 4).
Table 61-8 Files in /var/adm Directory
File |
Description |
---|---|
dtmp |
Output from the acctdusg program |
fee |
Output from the chargefee program, ASCII tacct records |
pacct |
Active process accounting file |
pacctn |
Process accounting files switched using turnacct |
Spacctn.MMDD |
Process accounting files for MMDD during execution of runacct |
The /var/adm/acct directory contains the nite, sum, and fiscal directories, which contain the actual data collection files. For example, the nite directory contains files that are reused daily by the runacct procedure. A brief summary of the files in the /var/adm/acct/nite directory follows.
Table 61-9 Files in the /var/adm/acct/nite Directory
File |
Description |
---|---|
active |
Used by runacct to record progress and print warning and error messages |
activeMMDD |
Same as active after runacct detects an error |
cms |
ASCII total command summary used by prdaily |
ctacct.MMDD |
Connect accounting records in tacct.h format |
ctmp |
Output of acctcon1 program, connect session records in ctmp.h format (acctcon1 and acctcon2 are provided for compatibility purposes) |
daycms |
ASCII daily command summary used by prdaily |
daytacct |
Total accounting records for one day in tacct.h format |
disktacct |
Disk accounting records in tacct.h format, created by the dodisk procedure |
fd2log |
Diagnostic output during execution of runacct |
lastdate |
Last day runacct executed (in date +%m%d format) |
lock |
Used to control serial use of runacct |
lineuse |
tty line usage report used by prdaily |
log |
Diagnostic output from acctcon |
log.MMDD |
Same as log after runacct detects an error |
owtmp |
Previous day's wtmp file |
reboots |
Beginning and ending dates from wtmp and a listing of reboots |
statefile |
Used to record current state during execution of runacct |
tmpwtmp |
wtmp file corrected by wtmpfix |
wtmperror |
Place for wtmpfix error messages |
wtmperror.MMDD |
Same as wtmperror after runacct detects an error |
runacct's copy of the wtmp file |
The sum directory contains the cumulative summary files updated by runacct and used by monacct. A brief summary of the files in the /var/adm/acct/sum directory is in Table 61-10.
Table 61-10 Files in the /var/adm/acct/sum Directory
File |
Description |
---|---|
cms |
Total command summary file for current fiscal period in internal summary format |
cmsprev |
Command summary file without latest update |
daycms |
Command summary file for the day's usage in internal summary format |
loginlog |
Record of last date each user logged on; created by lastlogin and used in the prdaily program |
rprt.MMDD |
Saved output of prdaily program |
tacct |
Cumulative total accounting file for current fiscal period |
tacctprev |
Same as tacct without latest update |
tacct.MMDD |
Total accounting file for MMDD |
The fiscal directory contains periodic summary files created by monacct. A brief description of the files in the /var/adm/acct/fiscal directory is in Table 61-11.
Table 61-11 Files in the /var/adm/acct/fiscal Directory
File |
Description |
---|---|
cmsn |
Total command summary file for fiscal period n in internal summary format |
fiscrptn |
Report similar to rprtn for fiscal period n |
tacctn |
Total accounting file for fiscal period n |
The most useful files produced by runacct (found in /var/adm/acct) are shown in Table 61-12.
Table 61-12 Files Produced by runacct
File |
Description |
---|---|
nite/lineuse |
runacct calls acctcon to gather data on terminal line usage from /var/adm/acct/nite/tmpwtmp and writes the data to /var/adm/acct/nite/lineuse. prdaily uses this data to report line usage. This report is especially useful for detecting bad lines. If the ratio between the number of logouts to logins is greater than about three to one, there is a good possibility that the line is failing. |
nite/daytacct |
This file is the total accounting file for the day in tacct.h format. |
sum/tacct |
This file is the accumulation of each day's nite/daytacct and can be used for billing purposes. It is restarted each month or fiscal period by the monacct procedure. |
sum/daycms |
runacct calls acctcms to process the data about the commands used during the day. This information is stored in /var/adm/acct/sum/daycms. It contains the daily command summary. The ASCII version of this file is /var/adm/acct/nite/daycms. |
sum/cms |
This file is the accumulation of each day's command summaries. It is restarted by the execution of monacct. The ASCII version is nite/cms. |
sum/loginlog |
runacct calls lastlogin to update the last date logged in for the logins in /var/adm/acct/sum/loginlog. lastlogin also removes from this file logins that are no longer valid. |
sum/rprt.MMDD |
Each execution of runacct saves a copy of the daily report that was printed by prdaily. |