3    Customizing the System Environment

This chapter provides information that enables you to customize your system environment. During the initial installation and configuration of your system, you may have already performed some of these tasks. As your system needs change, you may need to perform some of these additional tasks to meet new workload requirements. For example, during installation, you created the initial swap space (virtual memory). If you add physical memory to a system, you may need to increase the swap space correspondingly.

The following topics are covered in this chapter:

Refer to the following documents for information about customizing security and the network environment:

3.1    Identifying and Modifying the System Initialization Files

To define and customize the system environment, you modify certain initialization files that specify and control processes and run levels. The operating system provides you with default files that define the available run levels and the processes associated with each run level. You can easily change or customize the system environment by using these files as templates. In addition, if you support internationalization standards, you must be familiar with the structure and requirements of the corresponding files on your system.

The following sections describe this feature and provide instructions for identifying, using, and modifying the files that initialize and control the system environment. To understand and utilize available features, you should familiarize yourself with the init program and the specific files and commands associated with the program. Refer to the init(8) reference page for a description of the program and its behavior.

Before you make any changes to the system initialization files, examine the default setup, evaluate the needs of your system, and make a copy of the entire set of default files. Taking precautions is wise when making changes to system files or to files that alter the working environment. If you discover that your modifications do not create the environment that you intended, you can reinstate the default files while you fix the problems in your customization.

The following system files and directories influence system startup and operation:

/etc/inittab

One of the key initialization files whose entries define run levels and associated processes and administer terminals. Section 3.1.1 describes this file.

/etc/securettys

A text file that marks whether a given terminal (tty) line allows root logins. Section 3.1.1.6 describes this file.

/sbin/bcheckrc

A system initialization run command script associated with checking and mounting file systems at startup time. Section 3.1.1.2 describes this file.

/sbin/init.d

The initialization directory that contains executable files associated with system startup and the available run levels. Section 3.1.2.1 describes the directory structure and contents.

/sbin/rcn .d

A set of individual directories that correspond to the various run levels. Each directory contains linked files that the system acts on when starting or changing a particular run level. There are three /sbin/rcn .d directories available: /sbin/rc0.d, /sbin/rc2.d, and /sbin/rc3.d. Section 3.1.2.2, Section 3.1.2.3, and Section 3.1.2.4 describe the rc directory structure and contents.

/sbin/rcn

The run command script that corresponds to a particular run level. There are three /sbin/rcn scripts available: /sbin/rc0, /sbin/rc2, and /sbin/rc3. Section 3.1.2.2, Section 3.1.2.3, and Section 3.1.2.4 describe the contents and use of these scripts.

/etc/rc.config and /etc/rc.config.common

A file that contains run-time configuration variables. Scripts in the /sbin/init.d directory use these variables to configure various subsystems (for example, NFS or NTP). You (or a program) can use the rcmgr command to define or access variables in the /etc/rc.config file. Refer to the rcmgr(8) reference page and the Network Administration manual for more information.

/etc/sysconfigtab

The database file that contains information about the subsystems that can be dynamically configured. Chapter 4 describes this file.

/usr/sbin/getty

The executable file that sets and manages terminal lines. Section 3.1.1.3 and Section 3.1.1.4 describe this program. Refer to the getty(8) reference page for more information.

/etc/gettydefs

The file used by getty that contains entries to identify and define terminal line attributes. Refer to the gettydefs(4) reference page for more information.

/var/spool/cron/crontabs/*

The files that contain entries to identify and define the regular or periodic activation of specific processes. Refer to Section 3.1.3 for more information about these files.

/var/spool/cron/atjobs/*

The file that contains entries to identify and define the once-only activation of specific processes. See the at(1) reference page for more information.

The following files contain information on kernel configuration:

/usr/sys/conf/NAME

The text file that defines the components that the system builds into your configuration. The NAME variable usually specifies the system name. Chapter 4 describes this file.

/usr/sys/conf/NAME .list

The optional configuration file that stores information about the layered product subsystems and is used to automatically configure static subsystems. The NAME variable usually specifies the system name. Chapter 4 describes this file.

/usr/sys/conf/param.c

The text file that contains default values for some tunable system parameters used in building the system's kernel. Chapter 4 describes this file.

3.1.1    Using the /etc/inittab File

One of the first actions taken by the init program is to read the /etc/inittab file. The inittab file supplies the init program with instructions for creating and running initialization processes. The init program reads the inittab file each time init is invoked. The file typically contains instructions for the default initialization, the creation and control of processes at each run level, and the getty line process that controls the activation of terminal lines.

The operating system provides you with a basic /etc/inittab file that contains line entries for the most common and necessary initialization processes. For example, the /etc/inittab file available with the distribution software would look similar to the following: 

 is:3:initdefault: ss:Ss:wait:/sbin/rc0 shutdown </dev/console> \
    /dev/console 2>&1
 s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1
 fs:23:wait:/sbin/bcheckrc < /dev/console > /dev/console 2>&1
 kls:Ss:sysinit:/sbin/kloadsrv < /dev/console > /dev/console 2>&1
 hsd:Ss:sysinit:/sbin/hotswapd < /dev/console > /dev/console 2>&1
 sysconfig:23:wait:/sbin/init.d/autosysconfig start \
   < /dev/console > /dev/console 2>&1 
 update:23:wait:/sbin/update > /dev/console 2>&1
 smsync:23:wait:/sbin/sysconfig -r vfs smoothsync-age=30 > \
   /dev/null 2>&1
 smsyncS:Ss:wait:/sbin/sysconfig -r vfs smoothsync-age=0 > \
   /dev/null 2>&1
 it:23:wait:/sbin/it < /dev/console > /dev/console 2>&1 
 kmk:3:wait:/sbin/kmknod > /dev/console 2>&1
 s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1
 s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1
 cons:1234:respawn:/usr/sbin/getty console console vt100

The inittab file is composed of an unlimited number of lines, each with four fields; each field is separated by a colon. The fields and syntax for entries in the inittab file are as follows:

Identifier: Runlevel: Action: Command

Identifier

This 14-character field uniquely identifies an object entry.

Runlevel

This 20-character field defines the run levels in which the object entry is to be processed. The Runlevel variable corresponds to a configuration of processes in a system. Each process spawned by the init command is assigned one or more run levels in which it is allowed to exist. The run levels are as follows:

0 Specifies the halt state
s or S Specifies single-user mode
2 Specifies multiuser mode without network services
3 Specifies multiuser mode with network services

The Runlevel field can define multiple run levels for a process by specifying more than one run level character in any combination.

Action

This 20-character field tells init how to treat the specified process. The most common actions that init recognizes are as follows:

respawn

If the process does not exist or dies, init starts it. If the process currently exists, init does nothing and continues scanning the inittab file.

wait

When init enters a run level that matches the run level of the entry, it starts the process and waits for its termination. As long as init continues in this run level, it does not act on subsequent reads of the entry in the inittab file.

initdefault

A line with this action is processed when init is first invoked. The init program uses this line to determine which run level to enter. To do this, it takes the highest run level specified in the run-level field and uses that as its initial state. If the run-level field is empty, this is interpreted as 0s23, so init enters run level 3. If init does not find an initdefault line in the inittab file, it requests an initial run level from the operator.

Other action keywords are available and recognized by the init program. See the inittab(4) reference page for more information.

Command

This 1024-character field holds the sh command to be executed. The entry in the command field is prefixed with exec. Any legal sh syntax can appear in the command field.

You can insert comments in the inittab file by specifying a # (number sign) at the beginning of a line. You can also place a \ (line continuation character) at the end of a line.

If you intend to change or add entries to the /etc/inittab file, make certain that you are familiar with the function and contents of the associated files and run command scripts.

The following sections provide information that will help you to use the /etc/inittab file.

3.1.1.1    Specifying the Initialization Default Run Level

At boot time, the init program examines the inittab file for the initdefault keyword to find the definition of the run level to enter. If there is no entry in inittab for initdefault, the system prompts you for a run level. In the previous inittab file example, the following line indicates that the run level for initdefault is set to 3, which is the multiuser with network services mode: 

is:3:initdefault:

3.1.1.2    Specifying wait Run Levels

The init program looks in the inittab file for the wait entries. In the previous inittab file example, the following line contains a wait entry: 

fs:23:wait:/sbin/bcheckrc < /dev/console > /dev/console 2>&1

In this case, the init program invokes the /sbin/bcheckrc script for the fs entry. Processes associated with this entry execute at run levels 2 and 3. Input comes from the system console (/dev/console). System and process error messages are sent to the console (> /dev/console 2>&1).

The bcheckrc run command script contains procedures associated with file system checking and mounting. See the /sbin/bcheckrc file for details.

3.1.1.3    Specifying Console Run Levels

Before you or anyone else can log in to your system, the getty program for nonworksystems and the xdm program for worksystems must set up the process that runs the login and shell programs for each terminal and workstation, respectively. Because a large portion of your initial work is done at the system console, the /etc/inittab file contains an entry for setting up a getty process for the console. The xdm process is started with a run-level script in the /sbin/rc3.d directory.

In the example of the inittab file shown in Section 3.1.1, the following line contains the entry for the system console: 

cons:1234:respawn:/usr/sbin/getty console console vt100

The init program is instructed to invoke the getty program, which sets the terminal line attributes for the system console ( /dev/console ). The run-level field specifies that the getty process executes at run levels 1, 2, 3, and 4. The respawn keyword tells init to re-create the getty process if the active process terminates. If the process is active, init does not respawn the process; if it terminates, the process is re-created.

Note

In general, you should not modify the system console entry in the inittab file unless you want to limit the system console's access to different run levels. By placing limitations on the range of run levels for this terminal line, you risk disabling the system console if the system enters a run level that prohibits execution of the console's getty process.

3.1.1.4    Specifying Terminals and Terminal Run Levels

To enable user logins at each terminal supported by your system, you must maintain support for the terminal types available at your site and define the run level and getty process for each supported terminal type. Use the following database and file:

The operating system supports a wide variety of terminal types. The terminfo database contains entries that describe each terminal type and its capabilities. The database is created by the tic program, which compiles the source files into data files. The terminfo source files typically consist of at least one device description that conforms to a particular format. See the terminfo(4) reference page for specific details on creating and compiling source files.

The /usr/lib/terminfo directory contains the source files, each of which has a .ti suffix, for example name.ti. After you compile the source files with the tic command, it places the output in a directory subordinate to /usr/lib/terminfo.

Various commands and programs rely on the files in these directories. Set your TERMINFO environment variable to the /usr/lib/terminfo directory to instruct programs that rely on the database for information to look there for relevant terminal information.

See the getty(8), gettydefs(4), and inittab(4) reference pages for information about defining terminal lines and managing terminal access.

3.1.1.5    Specifying Process Run Levels

Specific entries in the inittab file define the run command scripts that are to be executed when the system enters or changes to a particular run level. For example, the following inittab file entries specify the action to be taken by the init program at each of the available run levels: 

ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1
s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1
s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1
s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1

These entries are associated with the rc directory structure and are discussed in detail in Section 3.1.2.

3.1.1.6    Securing a Terminal Line

The /etc/securettys file indicates to the system whether terminals or pseudoterminals can be used for root logins. To enable root logins on a terminal line, include the path name in the /etc/securettys file. To enable root login on pseudoterminals, include the ptys keyword. You enable X displays for root login by including their display name, for example :0. By default, only the console and the X server line are set secure.

The following example of an /etc/securettys file shows root logins enabled on the console, on the X display, on two hard-wired or LAT lines, and on all pseudoterminals: 

/dev/console
:0
/dev/tty00
/dev/tty01
ptys

3.1.2    Using the init and rc Directory Structure

The operating system provides you with an initialization and run command directory structure. The structure has four main components: the init.d, rc0.d, rc2.d, and rc3.d directories. In addition, each of the rcn .d directories has a corresponding rcn run command script.

3.1.2.1    The init.d Directory

The /sbin/init.d directory contains the executable files associated with system initialization. For example, a listing of the directory contents would look similar to the following: 

.mrg..autosysconfig    evm                    recpasswd
.new..autosysconfig    gateway                rmtmpfiles
.new..rmtmpfiles       inet                   route
.proto..autosysconfig  inetd                  rwho
.proto..rmtmpfiles     insightd               savecore
admincheck             kmod                   security
advfsd                 lat                    sendmail
asudllink              lpd                    settime
asudna                 mfsmount               sia
asunbelink             motd                   smauth
asutcp                 ms_srv                 smsd
audit                  named                  snmpd
autosysconfig          netrain                startlmf
bin                    nfs                    streams
binlog                 nfsmount               syslog
crashdc                niffd                  timed
cron                   nis                    uucp
dhcp                   paging                 write
dia_s_k                preserve               ws
enlogin                presto                 xlogin
envmon                 quota                  xntpd
 
 

3.1.2.2    The rc0.d Directory and rc0 Run Command Script

The /sbin/rc0 script contains run commands that enable a smooth shutdown and bring the system to either a halt state or single-user mode. As described previously, the inittab file contains entries that the init program reads and acts on when the system is shutting down to single-user mode (level s) or halting (level 0). For example: 

ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1
s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1

Notice that in both cases, the rc0 script is the specified command. In addition to commands listed in the script itself, rc0 contains instructions to run commands found in the /sbin/rc0.d directory. These commands are linked to files in the init.d directory. The script defines the conditions under which the commands execute; some commands run if the system is being halted while others run if the system is being shut down and rebooted to single-user mode.

By convention, files in the /sbin/rc0.d directory begin with either the letter "K" or the letter "S" and are followed by a 2-digit number and a file name. For example, a long listing of the rc0.d directory contents would look similar to the following: 

lrwxr-xr-x 1 root bin    17 May  8 16:35 K00enlogin -> ../init.d/enlogin
lrwxrwxrwx 1 root bin    16 May 10 10:05 K02.0ms_srv -> ../init.d/ms_srv
lrwxrwxrwx 1 root bin    16 May 10 10:03 K02.1asutcp -> ../init.d/asutcp
lrwxrwxrwx 1 root bin    20 May 10 10:03 K02.2asunbelink -> \
                                                    ../init.d/asunbelink
lrwxrwxrwx 1 root bin    16 May 10 10:03 K02.3asudna -> ../init.d/asudna
lrwxrwxrwx 1 root bin    19 May 10 10:03 K02.4asudllink -> \
                                                     ../init.d/asudllink
lrwxrwxrwx 1 root bin    13 May  8 16:39 K05lpd -> ../init.d/lpd
lrwxrwxrwx 1 root bin    13 May 10 11:06 K07lat -> ../init.d/lat
lrwxr-xr-x 1 root bin    15 May  8 16:35 K08audit -> ../init.d/audit
lrwxrwxrwx 1 root bin    14 May 10 11:06 K09dhcp -> ../init.d/dhcp
lrwxr-xr-x 1 root bin    15 May  8 16:37 K10inetd -> ../init.d/inetd
lrwxr-xr-x 1 root bin    15 May  8 16:37 K14snmpd -> ../init.d/snmpd
lrwxrwxrwx 1 root system 16 May 10 11:06 K16envmon -> ../init.d/envmon
lrwxr-xr-x 1 root bin    16 May  8 16:37 K19xlogin -> ../init.d/xlogin
lrwxr-xr-x 1 root bin    15 May  8 16:37 K20xntpd -> ../init.d/xntpd
lrwxr-xr-x 1 root bin    15 May  8 16:37 K21timed -> ../init.d/timed
lrwxr-xr-x 1 root bin    14 May  8 16:35 K22cron -> ../init.d/cron
lrwxr-xr-x 1 root bin    18 May  8 16:35 K25sendmail -> \
                                                    ../init.d/sendmail
lrwxrwxrwx 1 root bin    13 May  8 16:37 K30nfs -> ../init.d/nfs
lrwxr-xr-x 1 root bin    16 May  8 16:35 K31presto -> ../init.d/presto
lrwxrwxrwx 1 root bin    18 May  8 16:37 K35nfsmount -> \
                                                    ../init.d/nfsmount
lrwxr-xr-x 1 root bin    13 May  8 16:37 K38nis -> ../init.d/nis
lrwxrwxrwx 1 root bin    15 May 10 11:06 K40named -> ../init.d/named
lrwxr-xr-x 1 root bin    14 May  8 16:37 K42rwho -> ../init.d/rwho
lrwxr-xr-x 1 root bin    15 May  8 16:37 K43route -> ../init.d/route
lrwxr-xr-x 1 root bin    17 May  8 16:37 K44gateway -> \
                                                      ../init.d/gateway
lrwxr-xr-x 1 root bin    16 May  8 16:35 K45syslog -> ../init.d/syslog
lrwxrwxrwx 1 root bin    14 May 10 11:07 K46uucp -> ../init.d/uucp
lrwxr-xr-x 1 root bin    15 May  8 16:35 K47write -> ../init.d/write
lrwxr-xr-x 1 root bin    16 May  8 16:35 K48binlog -> ../init.d/binlog
lrwxr-xr-x 1 root bin    14 May  8 16:37 K50inet -> ../init.d/inet
lrwxr-xr-x 1 root bin    17 May  8 16:37 K50netrain -> \
                                                     ../init.d/netrain
lrwxr-xr-x 1 root bin    15 May  8 16:37 K51niffd -> ../init.d/niffd
lrwxr-xr-x 1 root bin    15 May  8 16:35 K52quota -> ../init.d/quota
lrwxr-xr-x 1 root bin    13 May  8 16:35 K95evm -> ../init.d/evm
lrwxr-xr-x 1 root bin    14 May  8 16:35 K96acct -> ../init.d/acct

In general, the system starts commands that begin with the letter "S" and stops commands that begin with the letter "K." The numbering of commands in the /sbin/rc0.d directory is important because the numbers are sorted and the commands are run in ascending order.

See the rc0(8) reference page for additional information.

3.1.2.3    The rc2.d Directory and rc2 Run Command Script

The /sbin/rc2 script contains run commands that enable initialization of the system to a nonnetworked multiuser state, run level 2. As described previously, the inittab file contains entries that the init program reads and acts on when the system is booting or changing its state to run level 2. For example: 

s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1
 

Notice that the rc2 script is the specified command. In addition to commands listed in the script itself, rc2 contains instructions to run commands found in the /sbin/rc2.d directory. These commands are linked to files in the init.d directory. The script defines the conditions under which the commands execute; some commands run if the system is booting, other commands run if the system is changing run levels.

By convention, files in the /sbin/rc2.d directory begin with either the letter "K" or the letter "S" and are followed by a 2-digit number and a file name. For example, a listing of the /sbin/rc2.d directory contents would look similar to the following: 

lrwxr-xr-x 1 root  bin    17 May  8 16:35 K00enlogin -> ../init.d/enlogin
lrwxrwxrwx 1 root  bin    16 May 10 10:05 K02.0ms_srv -> ../init.d/ms_srv
lrwxrwxrwx 1 root  bin    16 May 10 10:03 K02.1asutcp -> ../init.d/asutcp
lrwxrwxrwx 1 root  bin    20 May 10 10:03 K02.2asunbelink -> \
                                                       ../init.d/asunbelink
lrwxrwxrwx 1 root  bin    16 May 10 10:03 K02.3asudna -> ../init.d/asudna
lrwxrwxrwx 1 root  bin    19 May 10 10:03 K02.4asudllink -> \
                                                        ../init.d/asudllink
lrwxrwxrwx 1 root  bin    13 May  8 16:39 K05lpd -> ../init.d/lpd
lrwxrwxrwx 1 root  bin    13 May 10 11:06 K07lat -> ../init.d/lat
lrwxr-xr-x 1 root  bin    15 May  8 16:35 K08audit -> ../init.d/audit
lrwxrwxrwx 1 root  bin    14 May 10 11:06 K09dhcp -> ../init.d/dhcp
lrwxr-xr-x 1 root  bin    15 May  8 16:37 K10inetd -> ../init.d/inetd
lrwxr-xr-x 1 root  bin    15 May  8 16:37 K14snmpd -> ../init.d/snmpd
lrwxrwxrwx 1 root  system        16 May 10 11:06 K16envmon -> \
                                                          ../init.d/envmon
lrwxr-xr-x 1 root  bin    16 May  8 16:37 K19xlogin -> ../init.d/xlogin
lrwxr-xr-x 1 root  bin    15 May  8 16:37 K20xntpd -> ../init.d/xntpd
lrwxr-xr-x 1 root  bin    15 May  8 16:37 K21timed -> ../init.d/timed
lrwxr-xr-x 1 root  bin    14 May  8 16:35 K22cron -> ../init.d/cron
lrwxr-xr-x 1 root  bin    18 May  8 16:35 K25sendmail -> \
                                                        ../init.d/sendmail
lrwxrwxrwx 1 root  bin    13 May  8 16:37 K30nfs -> ../init.d/nfs
lrwxr-xr-x 1 root  bin    16 May  8 16:35 K31presto -> ../init.d/presto
lrwxrwxrwx 1 root  bin    18 May  8 16:37 K35nfsmount -> \
                                                        ../init.d/nfsmount
lrwxr-xr-x 1 root  bin    13 May  8 16:37 K38nis -> ../init.d/nis
lrwxrwxrwx 1 root  bin    15 May 10 11:06 K40named -> ../init.d/named
lrwxr-xr-x 1 root  bin    14 May  8 16:37 K42rwho -> ../init.d/rwho
lrwxr-xr-x 1 root  bin    15 May  8 16:37 K43route -> ../init.d/route
lrwxr-xr-x 1 root  bin    17 May  8 16:37 K44gateway -> \
                                                         ../init.d/gateway
lrwxr-xr-x 1 root  bin    16 May  8 16:35 K45syslog -> ../init.d/syslog

In general, the system starts commands that begin with the letter "S" and stops commands that begin with the letter "K." Commands that begin with the letter "K" run only when the system is changing run levels from a higher to a lower level. Commands that begin with the letter "S" run in all cases. The numbering of commands in the /sbin/rc2.d directory is important because the numbers are sorted and the commands are run in ascending order.

Refer to the rc2(8) reference page for more information.

3.1.2.4    The rc3.d Directory and rc3 Run Command Script

The /sbin/rc3 script contains run commands that enable initialization of the system to a networked multiuser state, run level 3. As described previously, the inittab file contains entries that the init program reads and acts on when the system is booting or changing its state to run level 3. For example: 

s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1
 

Notice that the rc3 script is the specified command. In addition to commands listed in the script itself, rc3 contains instructions to run commands found in the /sbin/rc3.d directory. These commands are linked to files in the init.d directory. The script defines the conditions under which the commands execute; some commands run if the system is booting, other commands run if the system is changing run levels.

By convention, files in the /sbin/rc3.d directory begin with the letter "S" and are followed by a 2-digit number and a file name. For example, a long listing of the rc3.d directory contents would look similar to the following: 

lrwxr-xr-x 1 root  bin    15 May  8 16:37 S00cniffd -> ../init.d/niffd
lrwxr-xr-x 1 root  bin    17 May  8 16:37 S00fnetrain -> ../init.d/netrain
lrwxr-xr-x 1 root  bin    14 May  8 16:37 S00inet -> ../init.d/inet
lrwxr-xr-x 1 root  bin    15 May  8 16:35 S01quota -> ../init.d/quota
lrwxrwxrwx 1 root  bin    14 May 10 11:07 S04uucp -> ../init.d/uucp
lrwxr-xr-x 1 root  bin    18 May  8 16:35 S08startlmf -> ../init.d/startlmf
lrwxr-xr-x 1 root  bin    16 May  8 16:35 S09syslog -> ../init.d/syslog
lrwxr-xr-x 1 root  bin    16 May  8 16:35 S10binlog -> ../init.d/binlog
lrwxr-xr-x 1 root  bin    17 May  8 16:37 S11gateway -> ../init.d/gateway
lrwxr-xr-x 1 root  bin    15 May  8 16:37 S12route -> ../init.d/route
lrwxr-xr-x 1 root  bin    14 May  8 16:37 S13rwho -> ../init.d/rwho
lrwxr-xr-x 1 root  bin    17 May  8 16:35 S14settime -> ../init.d/settime
lrwxrwxrwx 1 root  bin    15 May 10 11:06 S15named -> ../init.d/named
lrwxr-xr-x 1 root  bin    13 May  8 16:37 S18nis -> ../init.d/nis
lrwxrwxrwx 1 root  bin    13 May  8 16:37 S19nfs -> ../init.d/nfs
lrwxrwxrwx 1 root  bin    18 May  8 16:37 S20nfsmount -> ../init.d/nfsmount
lrwxr-xr-x 1 root  bin    15 May  8 16:35 S21audit -> ../init.d/audit
lrwxr-xr-x 1 root  bin    18 May  8 16:35 S25preserve -> ../init.d/preserve
lrwxr-xr-x 1 root  bin    20 May  8 16:35 S30rmtmpfiles -> ../init.d/rmtmpfiles
lrwxr-xr-x 1 root  bin    16 May  8 16:35 S36presto -> ../init.d/presto
lrwxr-xr-x 1 root  bin    18 May  8 16:35 S40sendmail -> ../init.d/sendmail
lrwxr-xr-x 1 root  bin    15 May  8 16:37 S45xntpd -> ../init.d/xntpd
lrwxr-xr-x 1 root  bin    15 May  8 16:37 S46timed -> ../init.d/timed
lrwxr-xr-x 1 root  bin    15 May  8 16:37 S49snmpd -> ../init.d/snmpd
lrwxrwxrwx 1 root  bin    18 May  8 16:44 S50insightd -> ../init.d/insightd
lrwxrwxrwx 1 root  system 16 May 10 11:06 S51envmon -> ../init.d/envmon
lrwxrwxrwx 1 root  bin    16 May  8 16:41 S53advfsd -> ../init.d/advfsd
lrwxr-xr-x 1 root  bin    15 May  8 16:37 S55inetd -> ../init.d/inetd
lrwxrwxrwx 1 root  bin    14 May 10 11:06 S56dhcp -> ../init.d/dhcp
lrwxr-xr-x 1 root  bin    14 May  8 16:35 S57cron -> ../init.d/cron
lrwxrwxrwx 1 root  bin    13 May 10 11:06 S58lat -> ../init.d/lat
lrwxr-xr-x 1 root  bin    14 May  8 16:35 S60motd -> ../init.d/motd
lrwxrwxrwx 1 root  bin    19 May 10 10:03 S61.0asudllink -> \
                                                        ../init.d/asudllink
lrwxrwxrwx 1 root  bin    16 May 10 10:03 S61.1asudna -> ../init.d/asudna
lrwxrwxrwx 1 root  bin    20 May 10 10:03 S61.2asunbelink -> \
                                                       ../init.d/asunbelink
lrwxrwxrwx 1 root  bin    16 May 10 10:03 S61.3asutcp -> ../init.d/asutcp
lrwxrwxrwx 1 root  bin    16 May 10 10:05 S61.4ms_srv -> ../init.d/ms_srv
lrwxr-xr-x 1 root  bin    15 May  8 16:35 S63write -> ../init.d/write
lrwxrwxrwx 1 root  bin    13 May  8 16:39 S65lpd -> ../init.d/lpd
lrwxr-xr-x 1 root  bin    17 May  8 16:35 S80crashdc -> ../init.d/crashdc
lrwxr-xr-x 1 root  bin    12 May  8 16:45 S90ws -> ../init.d/ws
lrwxr-xr-x 1 root  bin    16 May  8 16:37 S95xlogin -> ../init.d/xlogin
lrwxr-xr-x 1 root  bin    13 May  8 16:35 S97evm -> ../init.d/evm
lrwxr-xr-x 1 root  bin    16 May  8 16:35 S98smauth -> ../init.d/smauth
lrwxr-xr-x 1 root  bin    20 May  8 16:35 S99admincheck -> \
                                                     ../init.d/admincheck
lrwxr-xr-x 1 root  bin    14 May  8 16:38 S99smsd -> ../init.d/smsd

In general, the system starts commands that begin with the letter "S" and stops commands that begin with the letter "K." Commands that begin with the letter "K" run only when the system is changing run levels from a higher to a lower level. Commands that begin with the letter "S" run in all cases.

Usually, only commands that begin with the letter "S" are placed in the rc3.d directory. By default, run level 3 is the highest run level. The numbering of commands in the /sbin/rc3.d directory is important because the numbers are sorted and the commands are run in ascending order.

Refer to the rc3(8) reference page for more information.

3.1.3    Using the crontabs Directory

The crontab command submits a schedule of commands to the cron system clock daemon. The cron daemon runs shell commands according to the dates and times specified in the files in the /var/spool/cron/crontabs directory. Commands that you want to run on a regular schedule are in these files. Commands that you want to run only once are in the /var/spool/cron/atjobs/* files and are submitted with the at command.

The following example of an entry from a file in the /var/spool/cron/crontabs directory specifies that the runacct command runs at 2:00AM, Monday through Saturday, and output is sent to the /var/adm/acct/nite/fd2log file: 

   [1]                    [2]                      [3]
0 2 * * 1-6 /usr/sbin/acct/runacct > /var/adm/acct/nite/fd2log&

Each entry has the following syntax:

  1. Specifies the minutes past the hour, the hour, day of month, month, and day of week. Note that for the day of week, the value 0 (zero) indicates Sunday, the value 1 indicates Monday, and so on. You can specify a single value, more than one value separated by commas, or two values separated by a dash (-) to indicate a range of values. You can also specify an asterisk (*) to indicate no specific value. For example, if an asterisk (*) is specified for the hour, the command is run every hour. [Return to example]

  2. Specifies the command to be executed at the specified time. [Return to example]

  3. Specifies, optionally, arguments to the command. [Return to example]

To add a comment to a file, specify a # (number sign) at the beginning of the line.

The files in the /var/spool/cron/crontabs directory are named for system users, and the commands in the files are run under the authority of the user. For example, the commands in the adm file are run under adm authority.

To use the crontab command, you must be the user that matches the file name you want to act upon. For example, if you are user adm and you run the crontab command, the action is performed on the /var/spool/cron/crontabs/adm file.

To submit commands to the cron daemon to be run under adm authority:

  1. Become user adm.

  2. Enter the crontab command with the -l option to copy the /usr/spool/cron/crontabs/adm file to a temporary file in your home directory. 

    
% crontab -l > temp_adm

  3. Edit the temporary file and add the commands you want to run at a specified time.

  4. Enter the crontab command and specify the temporary file to submit the commands to the cron daemon. 

    % crontab temp_adm

The /var/adm/cron/log file contains a history of the commands executed by the cron daemon.

One important function of the file /usr/spool/cron/crontabs/root is to back up and clean system log files to prevent them from growing too large. A set of default cron tasks is configured when you install the operating system.

You can add additional tasks, or modify the existing tasks, to suit your local system requirements. For example, the root crontab file /usr/var/spool/crontabs/root contains three entries that will clean up system log files at 2:00AM every Sunday. One compressed backup of each log file is retained until the next cleaning. These crontab entries are enabled by default and appear in the file as follows: 

# To get the standard output by email remove the output redirection.
#
0 2 * * 0 /usr/lbin/logclean /var/adm/cron/log > /dev/null
0 2 * * 0 /usr/lbin/logclean /var/adm/wtmp > /dev/null
0 2 * * 0 /usr/lbin/logclean /var/adm/messages > /dev/null

Note that the output is directed to /dev/null by default. You can redirect it to e-mail to receive notification when a task finishes. These cron tasks backup the following log files and create a new empty file:

The preserved log files are located in /var/adm (/var/cluster/members/{memb}/adm), and are named with the suffix *.bak.gz. For example, wtmp.bak.gz. Use the command gunzip to decompress the files.

If you want to preserve your log files for a longer period of time, you can either change the frequency of the cleanup or comment out the applicable root crontab entries. You may also want to create cleanup cron tasks for other system log files, such as those relating to print services.

To edit the root crontab file, you must be root (superuser) and you should only use the following command: 

# crontab -e
 
 

The environment variable EDITOR should be set and exported beforehand if an editor other than /usr/bin/ed is desired.

Refer to the crontab(1) reference page for more information.

3.2    Using National Language Support

The operating system provides language-specific and country-specific information or support for programs.

The support components that concern you most directly as system administrator are the directories and files that reside at /usr/lib/nls.

An internationalized system presents information in a variety of ways. The word locale refers to the language, territory, and code set requirements that correspond to a particular part of the world. The system stores locale-specific data in two kinds of files:

Table 3-1 lists examples of the locales moved to the /usr/lib/nls/loc directory when you install the optional Single-Byte European Locales subset. Additional locales are installed by language variant subsets with special licensing requirements.

Table 3-1:  Locale Support Files

Language/Territory Locale Filename
Danish-Denmark da_DK.ISO8859-1
Dutch-Netherlands nl_NL.ISO8859-1
Dutch_Belgium nl_BE.ISO8859-1
English_U.K en_GB.ISO8859-1
English_U.S.A. en_US.ISO8859-1
Finnish-Finland fi_FI.ISO8859-1
French_Belgium fr_BE.ISO8859-1
French_Canada fr_CA.ISO8859-1
French_France fr_FR.ISO8859-1

Note

The /usr/lib/nls/loc directory also contains environment tables (.en files), character tables (.8859* files), and DEC variants (@DEC files) that correspond to some of the files listed in Table 3-1. These tables and variants are provided only to ensure system compatibility for old programs and should not be used by new applications.

For more information on internationalization options, and features provided to support the development of international software, refer to the following reference pages:

code_page(5)

Lists the coded character sets that are used on Microsoft Windows and Windows NT systems.

iconv_intro(5)

Provides an introduction to codeset conversion.

iconv(1)

Documents the command to convert encoded characters to another codeset.

i18n_intro(5)

Provides an introduction to internationalization (I18N).

i18n_printing(5)

Provides an introduction to internationalization (I18N) printer support.

l10n_intro(5)

Provides an introduction to localization (L10N).

locale(1)

Provides information about locales.

Note that this is not a definitive list of all the reference pages that document internationalization. Refer to the See Also section of each reference page, and the Writing Software for the International Market manual.

3.2.1    Setting Locale

The default system-wide locale for internationalization is the C locale. The default system-wide locale is the one that the setlocale function uses when a user does not set the internationalization environment variables, such as LANG, LC_COLLATE, and so on.

To change the system-wide default locale for Bourne and Korn shell users, edit the /etc/profile file and include the name of the locale you want to be the system-wide default. The setlocale function will then use the locale specified in this file. Those using the C shell can set a system-wide locale by editing the /etc/csh.login file and including the name of the locale you want to be the default system-wide locale.

You can set the native locale to any of the locales in the /usr/lib/nls/loc directory.

To set a locale, assign a locale name to one or more environment variables in the appropriate shell startup file. The simplest way is to assign a value to the LANG environment variable because it covers all components of a locale.

Note

The C locale is the system default. The C locale specifies U.S. English and uses the 7-bit ASCII codeset. The main difference between the C locale and the U.S. English locale (en_US.ISO8859-1) is that the latter has enhanced error messages.

The following example sets the locale to French for the C shell in which it is invoked and for all child processes of that shell: 


% setenv LANG fr_FR.ISO8859-1

If you want another shell to have a different locale, you can reset the LANG environment variable in that particular shell. The following example sets the locale to French for the Korn and Bourne shells: 


$ LANG=fr_FR.ISO8859-1
$ export LANG

Note that setting the LANG environment variable on the command line sets the locale for the current process only.

In most cases, assigning a value to the LANG environment variable is the only thing you need to do to set the locale. This is because when you set the locale with the LANG environment variable, the appropriate defaults are automatically set for the following functions:

In the unlikely event that you need to change the default behavior of any of the previous categories within a locale, you can set the variable that is associated with that category. See the following section for more information.

3.2.2    Modifying Locale Categories

When you set the locale with the LANG environment variable, defaults are automatically set for the collation sequence, character classification functions, date and time conventions, numeric and monetary formats, program messages, and the yes/no prompts appropriate for that locale. However, should you need to change any of the default categories, you can set the environment variables that are associated with one or more categories.

Table 3-2 describes the environment variables that influence locale categories.

Table 3-2:  Locale Environment Variables

Environment Variable Description
LC_ALL Overrides the setting of all other internationalization environment variables, including LANG.
LC_COLLATE Specifies the collating sequence to use when sorting names and when character ranges occur in patterns.
LC_CTYPE Specifies the character classification information to use.
LC_NUMERIC Specifies the numeric format.
LC_MONETARY Specifies the monetary format.
LC_TIME Specifies the date and time format.
LC_MESSAGES Specifies the language in which system messages will appear. In addition, specifies the strings that indicate ``yes'' and ``no'' in yes/no prompts.

As with the LANG environment variable, you can assign locale names to all of the category variables. For example, suppose that your company's main language is Spanish. You can set the locale with the LANG environment variable for Spanish, but set the numeric and monetary format for U.S. English. To do this for the C shell, you would make the following variable assignments: 

% setenv LANG es_ES.ISO8859-1
% setenv LC_NUMERIC en_US.ISO8859-1
% setenv LC_MONETARY en_US.ISO8859-1

Locale names may include @modifiers to indicate versions of the locales that meet special requirements for different categories.

For example, a locale might exist in two versions to sort data two ways: in dictionary order and in telephone-book order. Suppose your site is in France, uses the default French locale, and the standard setup for this locale uses dictionary order. However, your site also needs to use a site-defined locale that collates data in telephone-book order. You might set your environment variables for the C shell as follows: 


% setenv LANG fr_FR.ISO8859-1
% setenv LC_COLLATE fr_FR.ISO8859-1@phone

The explicit setting of LC_COLLATE overrides LANG's implicit setting of that portion of the locale.

3.2.3    Limitations of Locale Variables

The LANG and LC_* environment variables allow you to set the locale the way you want it, but they do not protect you from mistakes. There is nothing to protect you from setting LANG to a Swedish locale and LC_CTYPE to a Portuguese locale.

Also, there is no way to tie locale information to data. This means that the system has no way of knowing what locale you set when you created a file, and it does not prevent you from processing that data in inappropriate ways later. For example, suppose LANG was set to a German locale when you created file foo. Now suppose you reset LANG to a Spanish locale and then use the grep command for something in foo. The grep command will use Spanish rules on the German data in the file.

3.2.4    Setting Environment Variables for Message Catalogs and Locales

To define the location of message catalogs, set the NLSPATH environment variable. The default path is as follows: 

NLSPATH=/usr/lib/nls/msg/%L/%N:
 

In this example, %L specifies the current locale name, and %N specifies the value of name of the message catalog.

There is also a LOCPATH environment variable that defines the search path for locales. The default path is as follows: 

LOCPATH=/usr/lib/nls/loc:
 

3.3    Customizing Internationalization Features

The operating system provides many internationalization features. You, or your local site planners, determine which elements of the operating system's internationalization features (commonly called worldwide support features) are required. The worldwide support features are optional subsets that you can select during installation. Your job as an administrator is to set up and maintain these features for:

There are three sources of information about worldwide support:

3.4    Customizing Your Time Zone

Information about configuring your system's time zone is in Chapter 4. This section describes how to administer local and worldwide time zone information on your system.

Time zone information is stored in files in the /etc/zoneinfo directory. The /etc/zoneinfo/localtime file is linked to a file in the /etc/zoneinfo directory and specifies the local time zone. These files are linked during system installation, but, as superuser, you can change your local time zone by relinking the /etc/zoneinfo/localtime file. For example, the following command changes the local time zone to Canada's Atlantic time zone: 


# ln -sf /etc/zoneinfo/Canada/Atlantic /etc/zoneinfo/localtime

The /etc/zoneinfo/sources directory contains source files that specify the worldwide time zone and daylight savings time information that is used to generate the files in the /etc/zoneinfo directory. You can change the information in the source files and then use the zic command to generate a new file in the /etc/zoneinfo directory. Refer to the zic(8) reference page for more information.

You can also change the default time zone information by setting the TZ environment variable in your .login file or shell environment file. If you define the TZ environment variable, its value overrides the default time zone information specified by /etc/zoneinfo/localtime. By default, the TZ variable is not defined.

The TZ environment variable has the following syntax:

stdoffset [dst[offset] [,start[/time], end[/time]]]

You can also specify the following syntax:

stdoffset [ dst [ offset ] ]

The TZ environment variable syntaxes have the following parameters:

std and dst

Specifies the three or more characters that designate the standard (std) or daylight savings time (dst) zone.

Note

Daylight savings time is called daylight summer time in some locales.

The dst variable is not specified, daylight savings time does not apply. You can specify any uppercase and lowercase letters. A leading colon (:), comma (,), hyphen (-), plus sign(+), and ASCII NUL are not allowed.

offset

Specifies the value to be added to the local time to arrive at GMT. The offset variable uses 24-hour time and has the following syntax: 


hh [ :mm [ :ss ]]

If you do not specify the offset variable after the dst variable, daylight savings time is assumed to be 1 hour ahead of standard time. You can specify a minus sign (-) before the offset variable to indicate that the time zone is east of the prime meridian; west is the default, which you can specify with a plus sign (+).

start and end

Specifies when daylight savings time starts and ends. The start and end variable has the following syntaxes: 


Jj
n
 
Mm.w.d

In the first syntax, the j variable specifies the Julian day, which is between 1 and 365. The extra day in a leap year (February 29) is not counted.

In the second syntax, the n variable specifies the zero-based Julian day, which is between zero (0) and 365. The extra day in a leap year is counted.

In the third syntax, the m variable specifies the month number (from 1 to 12), the w variable specifies the week number (from 1 to 5), and the d variable specifies the day of the week (from 0 to 6), where zero (0) specifies Sunday and six (6) specifies Saturday.

time

Specifies the time, in local time, when the change occurs to or from daylight savings time. The time variable uses 24-hour time and has the following syntax: hh [ :mm [ :ss ] ]

The default is 02:00:00.

The following example of the TZ environment variable specification specifies: 

EST5EDT4,M4.1.0,M10.5.0

You can also specify the following syntax:

:pathname

The pathname variable specifies the pathname of a file that is in the tzfile file format and that contains the time conversion information. For example: 

:US/Eastern
 

Refer to the tzfile(4) reference page for more information on the file format.

If the pathname begins with a slash (/), it specifies an absolute pathname; otherwise, the pathname is relative to the /etc/zoneinfo directory. If the specified file is unavailable or corrupted, the system defaults to the offset stored in the kernel tz structure.

The time zone formats differ for SVID 2 and SVID 3. For SVID 2, /usr/sbin/timezone creates the /etc/svid2_tz file. The contents of the TZ and TZC variables are based on the information you supply when you run /usr/sbin/timezone.

For SVID 3, the /etc/svid3_tz file is created during the installation process. The contents of the TZ variable is based upon answers you supply to time zone-related questions at installation time.

Refer to the timezone(3) reference page for more information.

Refer to Chapter 4 for information about configuring a time zone for your system.

3.5    Customizing CPU Resource Allocation

The class scheduler provides you with a method of controlling the execution of tasks or applications by restricting the length of time that they can access the processor (CPU). For example, daemons such as the print spooler can be given less access time. The CPU will then have more time available to perform other tasks. To do this, you specify that the print daemon /usr/lbin/lpd is allowed to use no more than a certain percentage of the available CPU time. You can group resource user identifiers, such as a user's UID (user identification), into classes and assign the required CPU access time to each class.

This feature can help you to allocate system resources so that the most important work receives the required processing time. For example, you may want to run two versions of a production database on your system. One version is used as part of your business operations, while the other is a test copy, with different tuning parameters. The test database can be assigned to a different class so that your daily operations are not impacted by the testing.

To set up and use the class scheduler, you must complete the following steps:

You use the class scheduler commands to monitor and control scheduling as follows:

The following sections suggest a systematic approach to using class scheduling, although it is not be necessary to perform tasks in a specific sequence. There are two methods of accessing the class scheduler:

Manual

By executing class_admin commands from the command line to configure a default database, add classes and class members, and enable the class scheduling daemon to create a quick fix to a CPU resource sharing problem.

Graphical Interface

By using the graphical user interface available as a SysMan Menu sub-option, Class Scheduling, which is available under the Monitoring and Tuning menu option.

Refer to Chapter 1 for information on running the SysMan Menu. Section 3.5.6 describes how you use the graphical interface. Refer to the online help for additional information on valid data entries.

The following reference pages contain detailed information on using the class scheduler commands and options:

The following command displays online help for the class_admin command: 

# /usr/sbin/class_admin help
 
 

3.5.1    Class Scheduler Overview

To use the class scheduler, you must first create a database file and populate the file with one or more classes. Each class is assigned a CPU value that controls its access to processing time, expressed as a percentage of the total CPU time availability. One or more applications or groups of applications can be assigned to a class, identified according to a unique system process identifier such as:

Note that the PID, PGID, and SESS identifiers are usually temporary and do not persist across a reboot, ceasing to exist when a task is completed. They are not stored in the database and have no effect when the system or task is restarted.

Once the database is established, you can enable class scheduling to start a class scheduling daemon and put the CPU access restrictions into effect. Other commands enable you to review classes, change contents or scheduling parameters, and delete components or entire classes. When a class scheduling database is configured and enabled, you can:

3.5.1.1    Related Utilities

The following utilities are also available for use when monitoring and tuning processes:

3.5.1.2    Invoking the Class Scheduler

The class scheduler is provided as both a command-line interface and a graphical user interface. You can invoke the class scheduler several ways , depending on what user environment you are working from:

Note that the following sections focus on using the command-line method, and provide a brief introduction to using the graphical interface. Refer to the online help for more information in using the graphical interface.

3.5.2    Planning Class Scheduling

How you allocate CPU resources will depend on your system environment and what resources and priorities must be considered. A typical scenario is to assign a higher CPU percentage to interactive tasks so that users do not encounter long response times. Most batch or background processes will be assigned a lower CPU percentage, while some specific background processes may require a higher CPU percentage. For example, if a nightly back up is being performed, you might not want it to have such a low CPU percentage that it does not complete in a reasonable time.

If, however, your system is involved with critical real-time tasks that must take precedence over interactive processes, your course of action may be different. In such cases you should design a baseline that assigns processes to classes. You can then monitor processes and gather user feedback to tune the database by moving tasks from class to class or by changing the CPU access time of the classes.

3.5.3    Configuring Class Scheduling

Use the class_admin command to configure an initial database. This command provides:

A database must be configured before you can enable class scheduling with the enable command. If a database does not exist when you enter the class_admin command, the command will invoke an interactive session and prompt you to configure a database. If the class_admin command is invoked by a script, a database is configured automatically, using the system defaults.

The following example shows an interactive configuration session using class_admin. Note that in the actual output, the lines will be formatted to fit in 80 columns: 

# /usr/sbin/class_admin
                    Class Scheduler Administration
 
configure:
 
Shall processes that have not been explicitly
assigned to a defined class be assigned to a
'default' class?  Enter (yes/no) [no]: yes
 
Enforce class scheduling when the CPU is otherwise
idle? (yes/no) [no]: yes
 
How often do you want the system to reset class usage?
Enter number of seconds (1): 2
class>

The configuration values have the following effect:

In the example, a default class was created and all current processes were assigned to that class. Class scheduling will be enforced even when the CPU is idle and class usage will be reset every five seconds.

To review the current configuration, use the following command: 

class> show
Configuration:
 -Processes not explicitly defined in the database are
  class scheduled.
 -If the processor has some idle time, class scheduled
  processes are not allowed to exceed their cpu percentage.
 -The class scheduler will check class CPU usage every 2
  seconds.
 
Class scheduler status: disabled  current database: /etc/class
 
Classes:
 
 default targeted at 100%:
    class members:
    Every one not listed below

The next step in the process is to create classes and populate the classes with system processes such as tasks, daemons, or user accounts using the appropriate identifiers such as UID or SESS.

3.5.4    Creating and Managing Classes

When the database has been configured, you can administer classes as follows:

Some of these options are described briefly in the following sections, for detailed descriptions of command options, refer to the online help and reference pages.

3.5.4.1    Creating a Class

To create a class, either use the command mode or enter an interactive session as follows: 

# class_admin
class> create high_users 50

The command mode version is entered as follows: 


# class_admin create batch_jobs 10
batch_jobs created at 10% cpu usage
 
 
changes saved

The first command creates a class named high_users and assigns a CPU usage restriction of 50 percent. The second command creates a class named batch_jobs and assigns a CPU usage restriction of 10 percent. Note that in command mode the changes are automatically saved to the database in /etc/class. When making changes to classes interactively, you use the command save to commit changes to the database. If you attempt to end the session with the quit command and there are unsaved changes, you will be prompted to save or discard the changes before quitting the interactive session as follows: 

class> quit
Class scheduler database modified.
Save changes? (yes/no) [yes]:yes
 
changes saved

3.5.4.2    Managing Identifier Types Within Classes

Processes that are members of a class are identified by unique system-assigned identifiers that the class scheduler recognizes, such as the PID, GID, or UID.

Once you have created classes, you can add UIDs and GIDs or processes to one or more classes using the add command. You must specify the type of identifier (id) used and enter one or more unique identifiers. UIDs and GIDs can be determined from the /etc/passwd and /etc/group files. Alternatively, you can use the graphical interface Account Manager (dxaccounts) to display UID and Group information.

Process identifiers can be obtained from system files or by using a command such as ps. With the ps command, you can determine the values of PID, PGID and SESS. Using the following command, you can display the PID for every process running on the system: 


# /sbin/ps aj

 
 
USER   PID PPID  PGID  SESS JOBC S    TTY          TIME COMMAND
walt  5176 5162  5176  2908   1  S    ttyp1    0:01.30 -sh (csh)
root 12603 5176 12603  2908   1  R  + ttyp1    0:00.05 ps aj

See the ps(1) reference page for more information.

The following identifiers are supported:

gid

A group identification number from the /etc/group file. For example if you are adding members to a class, using this number will add all the users that are assigned to the group.

uid

A user identification number from the /etc/passwd file. For example if you are adding members to a class, this number will add only the specific user to which the UID is assigned.

pgrp

A process group identifier. In the output from the ps aj command, see the entries under the PGID table heading in the previous example.

session

A session identifier. In the output from the ps aj command, see the entries under the SESS table heading in the previous example.

pid

The process identifier. In the output from the ps aj command, see the entries under the PID table heading in the previous example.

It is most likely that you will use types uid and gid in your established classes, as these values will persist across a reboot or when class scheduling is stopped and restarted. You can use the account management tools, such as dxaccounts or the Accounts option of the SysMan Menu to list UIDs and GIDs for users and groups. The identifiers associated with types pgrp, session, and pid are temporary, and will not exist on reboot, or when a process terminates.

3.5.4.3    Enabling the Class Scheduler

To enable the class scheduler daemon, you execute the following command: 

# class_admin enable
Class scheduling enabled and daemon \
/usr/sbin/class_daemon started.

To disable the daemon, enter the following command: 

# class_admin disable
Class scheduling disabled.

3.5.4.4    Adding Members to a Class

To add a process to a class, you use the add command as shown in the following interactive mode example: 


class> add batch_jobs uid 234 457 235
 
 

Note that you must use one of the unique identifiers previously specified and you cannot add the same identifier to a class more than once. The same procedure can be performed in command mode or from a script as follows: 

# class_admin add batch_jobs uid 234 457 235
uid 234 457 235 added to high_users

In command mode, additions to a class are automatically saved to the /etc/class database.

3.5.4.5    Deleting Members From a Class

To delete one or more processes from a class, use the delete command in interactive or command mode. For example: 


class> delete high_users uid 11
uid 11 deleted from high_users

This example deletes the single UID number 11 from class high_users.

3.5.4.6    Other Class Management Options

Consult the class_admin(8) reference page for information on the following options:

3.5.5    Using the runclass Command

Once you have established scheduler classes and enabled class scheduling, you can use the runclass command to execute a command in a particular class. If you want a higher CPU percentage than is currently assigned to you, you must have root privileges to use this command. The following command uses the runclass command to open a terminal window and assign it to the previously-created high_users class: 

# runclass high_users xterm

The following command shows that the pgrp number for the terminal process is now identified as a member of that class: 

# class_admin show
.
.
.
class members:
pgrp 24330     pgrp 24351     pgrp 24373

In this example, the identifier for the xterm process has been added to the class. You can use the following command to view the running process: 

# ps agx | grep xterm

See the runclass(1) reference page for more information.

3.5.6    Using the Class Scheduling Graphical Interface

The class scheduler can be launched from the SysMan menu by selecting the Class Scheduling option from the Monitoring and Tuning tasks. Alternatively, you can launch it from the Common Desktop Environment (CDE) Application Manager. Refer to Chapter 1 for more information on using the SysMan Menu.

As for the command-line method of using the class scheduler described in preceding sections, the steps involved in initial configuration are as follows:

  1. Plan your classes and the processes, users, or groups that will be in each class.

  2. Configure and name a database by creating classes and adding them to the database.

  3. Define the new database as the current database.

  4. Start the class scheduling daemon.

You can complete these steps using the SysMan Menu Class Scheduling main menu option, where the following three suboptions are available:

Configure Class Scheduler

This is the main option that you use to configure and initialize class scheduling. When you select this option, a window is displayed titled Configure Class Scheduler on hostname. From here you can select one of the following options:

The New... option is the main option and the one most frequently used. It is described in detail in Section 3.5.6.1. The Modify... option provides an identical interface, which allows you to change existing classes and databases.

The remaining menu options require only a confirmation and do not involve extensive data entry. For example, if you opt to delete a database, you will only be prompted to confirm that the database is to be destroyed.

[Re]Start Class Scheduler

Use this option to start the class scheduling daemon, or restart it if it has been stopped. You will be prompted to confirm your selection.

Stop Class Scheduler

Use this option to stop the class scheduling daemon. You will be prompted to confirm your selection.

3.5.6.1    Creating or Modifying a Database

When you select the New... or Modify... options, a screen is displayed titled Configure Class Scheduler: Create/Modify Scheduling Database. Use the following steps to create a new database:

  1. In the Name: field, type the name of the database that you want to create. The name should reflect the function of the database, so that you can easily recognize it when it is displayed in a list of many options. For example, served_applications.

  2. From the option list titled Available Scheduled Classes, you can select any existing classes. If you are setting up the first database, no classes will be listed and only the New.. option will be available for selection.

  3. To create a new class, press the New... button to display the window titled Create a new class. In this window, you complete the following steps:

  4. When classes have been created, they appear as entries in the optional list of Available Scheduling Classes. Apart from the class name, the CPU time percentage allocation and member and type are also displayed. You can now select classes to add to the database as follows:

  5. When all required classes are selected, press the OK button to create the new database. The new database will be added to the list of Available Scheduling Databases.

You also use the Configure Class Scheduler: Create/Modify Scheduling Database window to perform maintenance and administrative operations on classes as follows:

To begin using the newly created database, complete the following steps:

  1. If the window titled Configure Class Scheduler on hostname is not already displayed, invoke the SysMan Menu and select the Configure Class Scheduler option.

  2. Highlight the required database by clicking on it, then press the Make Current... button. You will be prompted to confirm or cancel your choice.

  3. Press the OK button to return to the SysMan Menu, Class Scheduling options, and select the option titled [Re]Start Class Scheduler. You will be prompted to confirm your choice.

On completing these steps, the class scheduling daemon will be started, using the scheduling database that you specified. To verify and monitor that the database is working as anticipated, use the show command at the terminal command line. For example, to view scheduling statistics, enter the following command: 


# class_admin stats
 
Class scheduler status: enabled \
current database: /etc/.cl_lab1
 
class name     target percentage  actual percentage
prio-tasks-lab        10                  10

Note that you may need to spend some time monitoring tasks and system performance, and you may need to tune your classes to obtain the required results.

3.6    Customizing Power Management

The operating system contains features that allow you to conserve power on certain systems that have the appropriate hardware. In this release, power management has been extended to additional systems and is enabled on these systems by default. Refer to the owner's manual for information on whether your system supports power management. Power management utilities allow you to:

There are several methods to invoke and manage power conservation, using the following utilities:

3.6.1    Using the dxpower Utility's Graphical User Interface

The graphical user interface dxpower can be used on the graphics console of a host system or invoked from the command line. Certain features are password-protected, and can only be used by the system administrator on a root login. A nonprivileged user can control features such as the energy-saving features of a monitor. If you are using CDE, you can open the dxpower power management utility by performing the following steps:

  1. Click on the Application Manager icon.

  2. Double click on the System_Admin application group icon.

  3. Double click on the DailyAdmin application group icon.

  4. Double click on the Power Management icon.

If you are using a terminal or other X11 windowing environment, you can start the dxpower utility from the command line as follows: 

# /usr/bin/X11/dxpower

When the dxpower utility runs, a power management window is displayed on your screen. The window provides check boxes that you use to select modes of operation, and sliding scales (bars) that you use to specify idle time limits. Idle time is the amount of time elapsed before the device goes into power saving mode and can be set from 1 to 60 minutes. Depending on your login privileges, the graphical interface allows you to:

Caution

Monitors (displays) that do not support DPMS (Display Power Management Signaling) can be damaged by the activation of the DPMS feature. It is important that you check the specifications for your monitor in the owners manual. Monitors that support DPMS and are put in a power savings state will vary in the time it takes to come out of power savings. The longer the monitor is in power-off state, the longer it takes for the display to return as a result of mouse or keyboard activity. This is the result of the monitor phosphor cooling down and the time required to heat it back up, and not a function of the power management software.

For more information about how to use the dxpower utility, start the application and then click on the Help button in the lower right-hand corner of the window.

3.6.2    Using the sysconfig Command and sysconfigdb

You can control power management attributes from the command line by using sysconfig to manage the sysconfigdb database. For example, you will need to use sysconfig if you are activating power management for a system from a remote terminal or from a local console terminal.

If you activate the power management tools from a console terminal where CDE is not running, only the graphics_powerdown and graphics_off_dwell attributes apply. Changing the graphics_standby_dwell and graphics_suspend_dwell attribute values has no effect. See Section 3.6.2.1 for descriptions of these attributes.

Caution

Do not attempt to use sysconfig and dxpower simultaneously. If you do, you could encounter unpredictable behavior.

3.6.2.1    Changing Power Management Values

To change the power management values that take effect every time you restart the kernel, you create a stanza. See stanza(4) for more information. The stanza file can contain the following power management attributes:

For example, you can create a stanza file called power_mgr.stanza that defines the following values for the attributes: 

pwrmgr:
		default_pwrmgr_state=1
		cpu_slowdown=1
		disk_dwell_time=20
		disk_spindown=1
		graphics_powerdown=1
		graphics_standby_dwell=5
		graphics_suspend_dwell=10
		graphics_off_dwell=15

For the disk_dwell_time, graphics_standby_dwell, graphics_suspend_dwell, and graphics_off_dwell attributes, the specified values indicate the number of minutes to wait before powering down the idle hardware. In this case, the power management subsystem waits 20 minutes before disk spindown, and 5, 10, and 15 minutes before DPMS standby, suspend, and off modes, respectively. The remaining attributes, have a value of 1, which indicates that the function is enabled.

After you create and save the stanza file, enter the following command to update the /etc/sysconfigtab database: 

# sysconfigdb -a -f power_mgr.stanza pwrmgr

See the sysconfigdb(8) reference page for more information.

3.6.2.2    Changing a Running Kernel or X Server

To change the values of attributes in the running kernel, use the sysconfig -r command. For example: 


# sysconfig -r pwrmgr cpu_slowdown=0

You can change more than one attribute at a time, as shown in the following example: 

# sysconfig -r pwrmgr \
graphics_powerdown=1 graphics_standby_dwell=10

See the sysconfig(8) reference page for more information.

See the dpms switches in the Xdec(1X) and xset(1X) reference pages for information about changing DPMS modes and values in the X Server.

3.6.3    Using the SysMan Station

If you are using the SysMan Station, you can select system entities such as CPUs or disk devices from the system topology map.

Clicking MB3 on an icon will enable a list of management actions for the selected device, one of which may be the power management application dxpower. Selecting this menu item will run dxpower on the device.

3.7    Adding Swap Space

The operating system uses a combination of physical memory and swap space on disk to create virtual memory, which can be much larger than the physical memory. Virtual memory can support more processes than the physical memory alone. This section and the sections that follow describe important virtual memory concepts that you should consider when configuring swap space.

The virtual memory (vm) kernel subsystem controls the allocation of memory to processes by using a portion of physical memory, disk swap space, and various daemons and algorithms. A page is the smallest portion of physical memory that the system can allocate (8 KB of memory).

Virtual memory attempts to keep a process' most recently referenced virtual pages in physical memory. When a process references virtual pages, they are brought into physical memory from their storage locations on disk. Modified virtual pages can be moved to a temporary location on the disk (called swap space) if the physical pages (the pages in physical memory) that contain the virtual pages are needed by either a newly referenced virtual page or by a page with a higher priority. Therefore, a process' virtual address space can consist of pages that are located in physical memory, stored temporarily in swap space, and stored permanently on disk in executable or data files. Virtual memory operation involves:

Paging involves moving a single virtual page or a small cluster of pages between disk and physical memory. If a process references a virtual page that is not in physical memory, the operating system reads a copy of the virtual page from its permanent location on disk or from swap space into physical memory. This operation is called a pagein. Pageins typically occur when a process executes a new image and references locations in the executable image that have not been referenced before.

If a physical page is needed to hold a newly referenced virtual page or a page with a higher priority, the operating system writes a modified virtual page (or a small cluster of pages) that has not been recently referenced to the swap space. This operation is called modified page writing or a pageout. Note that only modified virtual pages are written to swap space because there is always a copy of the unmodified pages in their permanent locations on disk.

Swapping involves moving a large number of virtual pages between physical memory and disk. The operating system requires a certain amount of physical memory for efficient operation. If the number of free physical pages drops below the system-defined limit, and if the system is unable to reclaim enough physical memory by paging out individual virtual pages or clusters of pages, the operating system selects a low priority process and reclaims all the physical pages that it is using. It does this by writing all of its modified virtual pages to swap space. This operation is called a swapout. Swapouts typically occur on systems that are memory constrained.

3.7.1    Related Documentation and Utilities

The following documentation resources and utilities provide information on administering swap space:

The following utilities are used during swap space administration:

Caution

The ability of the system to save crash dumps after a system crash is also affected by the size and availability of swap space. If there is insufficient swap space allocation, the system will be unable to save a crash dump, which can contain valuable information that will assist you in recovering from errors. Refer to Chapter 12 for information on crash dump space requirements.

3.7.2    Allocating Swap Space

Swap space is initially planned and allocated during system installation, based on your requirements for the installed system. However, you may want to add swap space to improve system performance or if you added more physical memory to your system. A cue to increase swap space may be provided by system console warning messages, stating that available swap space is depleted. Before adding swap space, check that any sudden lack of space is not due to a system problem. Use the following command, or examine system log and event files to ensure that the swap space is not being used up by runaway processes or unusual user activity: 


# ps agx

If the resulting list of processes looks normal, you may need to add swap space.

Swap space can be added temporarily by running swapon. To make the additional swap permanent, you must add an entry to the vm section of the /etc/sysconfigtab file. The process is as follows:

  1. The swapon command will verify a disk partition to ensure that you do not write over data or use overlapping partitions. If you have a choice of disks, you will probably want to choose a location for swap on a convenient fast disk that does not have excessive I/O usage. For example, the disk where your user files are located probably has higher I/O demands.

    Use the diskconfig utility to examine disks and choose a suitable partition.

  2. Run swapon to create the swap partition, as shown in the following example: 

    # /sbin/swapon /dev/disk/dsk0b

    You may only require some temporary swap space, such as additional space to take a full crash dump instead of a partial dump. If this is the case, you do not need to take any further action and the swap partition is ready for use. To review the current swap configuration, use the following command: 

    
# /sbin/swapon -s

    Note that you can also repeat step 1 to add additional partitions if required.

  3. To make the additional swap space permanent, you must edit the vm section of the /etc/sysconfigtab file to include the new partition as follows:

See the swapon(8) reference page for information about how the command interacts with overlapping partitions.

The amount of swap space that your system requires depends on the swap space allocation strategy that you use and your system workload. Strategies are described in the following section.

3.7.3    Estimating Swap Space Requirements

There are two strategies for swap space allocation: immediate mode and deferred or over-commitment mode. The two strategies differ in the point in time at which swap space is allocated. In immediate mode, swap space is recovered when modifiable virtual address space is created. In deferred mode, swap space is not reserved or allocated until the system needs to write a modified virtual page to swap space.

Note

The operating system will terminate a process if it attempts to write a modified virtual page to swap space that is depleted.

Immediate mode is more conservative than deferred mode because each modifiable virtual page reserves a page of swap space when it is created. If you use the immediate mode of swap space allocation, you must allocate a swap space that is at least as large as the total amount of modifiable virtual address space that will be created on your system. Immediate mode requires significantly more swap space than deferred mode because it guarantees that there will be enough swap space if every modifiable virtual page is modified.

If you use the deferred mode of swap space allocation, you must estimate the total amount of virtual address space that will be both created and modified, and compare that total amount with the size of your system's physical memory. If this total amount is greater than half the size of physical memory, the swap space must be large enough to hold the modified virtual pages that do not fit into your physical memory. If your system's workload is complex and you are unable to estimate the appropriate amount of swap space by using this method, you should first use the default amount of swap space and adjust the swap space as needed. Typically, consider using a swap size of about half the size of physical memory.

You should always monitor your system's use of swap space. If the system issues messages that indicate that swap space is almost depleted, you can use the swapon command to allocate additional swap space. If you use the immediate mode, swap space depletion prevents you from creating additional modifiable virtual address space. If you use the deferred mode, swap space depletion may result in one or more processes being involuntarily terminated.

For more information on virtual memory, refer to the System Configuration and Tuning guide.

3.7.4    Selecting the Swap Space Allocation Method

To determine which swap space allocation method is being used, you can examine the vm: section of the /etc/sysconfigtab file. Alternatively, use dxkerneltuner or sysconfig to examine kernel attribute values. You will see an entry similar to the following: 

vm: 
                 swapdevice=/dev/disk/dsk1b, /dev/disk/dsk3h
                 vm-swap-eager=1

The entry for vm-swap-eager= determines the allocation method as follows:

Either edit the /etc/sysconfigtab file to change the current value, or alternatively, use dxkerneltuner or sysconfig to dynamically modify the attribute.

You must reboot the system for the new swap method to take effect. You may receive the following boot time informational messages when you switch to deferred mode or when you boot a system that is using the deferred method: 

vm_swap_init:  warning sbin/swapdefault swap device not found
vm_swap_init:  in swap over-commitment mode