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 performed some of these tasks already. 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 accordingly.

The following topics are covered in this chapter:

A description of the system initialization files, which you use to initialize and control the system's run levels (Section 3.1)

Information on using the national language directories to provide support for language-specific and country-specific programs (Section 3.2)

A discussion of the internationalization features, which you tailor to support programmers and users developing and running programs for international audiences (Section 3.3)

A discussion on the system time zone directories and environment variables, which you use to administer local and worldwide time zone information on your system (Section 3.4)

A description of power management, which you set up and use to control power consumption in Energy Star-compliant peripherals and processors (Section 3.5)

Information on how to customize swap space. See the System Configuration and Tuning manual as there are implications for performance tuning (Section 3.6)

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

The Technical Overview briefly describes the security components of the operating system.

The Security Administration and Security Programming manuals are the principal source of security-related information for users, administrators, and programmers dealing with the security components.

The Network Administration: Connections and Network Administration: Services manuals are the principal sources of information for customizing the system's networking components.

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 change or customize the system environment easily 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. See init(8) 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 verifying 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: The /sbin directory contains a set of individual subdirectories that correspond to the various run levels. Each subdirectory 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: These are the run command scripts that correspond 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: This is 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. See rcmgr(8) and the Network Administration: Connections and Network Administration: Services manuals for more information.
/etc/sysconfigtab: This is the database file that contains information about dynamically configurable subsystems. Chapter 4 describes this file.
/usr/sbin/getty: This is the executable file that sets and manages terminal lines. Section 3.1.1.3 and Section 3.1.1.4 describe this program. See getty(8) for more information.
/etc/gettydefs: The file used by getty that contains entries to identify and define terminal line attributes. See gettydefs(4) for more information.
/var/spool/cron/crontabs/*: These are the files that contain entries to identify and define the regular or periodic activation of specific processes. See Section 3.1.3 for more information about these files.
/var/spool/cron/atjobs/*: This is a file that contains entries to identify and define the once-only activation of specific processes. See at(1) for more information.

The following files contain information on kernel configuration:

/usr/sys/conf/NAME: This is a 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 line in the inittab file contains four fields that are 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. While 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 inittab(4) for more information.

Command

This is a data field limited to 1024 characters that contains sh commands. 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.

Before you modify or add entries to the /etc/inittab file, ensure that you are familiar with the function and contents of the associated files and the command scripts.

The following sections provide information to 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 verification 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, either the getty program or the xdm program must run. These programs set up a process that runs the login and shell programs for each terminal or workstation. 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 by 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 should execute at run levels 1, 2, 3, and 4. The respawn keyword tells init to recreate 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 recreated.

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 /usr/lib/terminfo database (a symbolic link to /usr/share/lib/terminfo) defines the various terminal types.

Entries in the /etc/inittab file define the run level and getty process for the supported terminal types.

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 terminfo(4) 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 getty(8), gettydefs(4), and inittab(4) 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 directory

The rc0.d directory

The rc2.d directory

The rc3.d directory

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

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 rc0(8) for more 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 run level 2 (multiuser, but disconnected from the network). The inittab file contains entries that are read by the init program. The init program reads and acts on the inittab file entries 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

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.

See rc2(8) 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

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.

See rc3(8) 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:00 A.M., 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:

Specifies the minutes past the hour, the hour, day of month, month, and day of week. 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]

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

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:

Become user adm.

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
```

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

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.

You can use the /usr/spool/cron/crontabs/root file to back up and clean system log files. The root crontab file /usr/var/spool/cron/crontabs/root contains a model entry to clean up the /var/adm/wtmp log file at 2:00 A.M. every Sunday. One compressed backup of the log file is retained until the next cleaning. This crontab entry is enabled by default as follows:

# To get the standard output by e-mail remove the output redirection.
#
0 2 * * 0 /usr/lbin/logclean /var/adm/wtmp > /dev/null

Add additional tasks, or modify the existing task, to suit your local system requirements.

In the preceding example, output is directed to /dev/null by default. You can redirect it to an e-mail address to receive notification when a task finishes. This cron task backs up the login log file and creates a new empty file. (The login log records all user logins on the system.)

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 ./crontabs/root entry. Also, you may 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 use only the following command:

# crontab -e

The environment variable EDITOR should be set and exported beforehand if you want to use an editor other than /usr/bin/ed.

See crontab(1) 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:

Locale files: These files contain month and day names, date formats, monetary and numeric formats, valid yes/no strings, character classification data, and collation sequences. These files reside in the /usr/lib/nls/loc directory.
Message catalogs: These files contain translations of messages that are used by programs. These files reside in the /usr/lib/nls/msg/locale-name directory.

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) and character tables (.8859* 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, see:

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.

This is not a definitive list of all the reference pages that document internationalization. The See Also section of each reference page, and the Writing Software for the International Market manual are definitive sources.

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. Then the setlocale function uses 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

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:

Collation

Character classification

Date and time conventions

Numeric and monetary formats

Program messages

Yes/no prompts

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 set automatically 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 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 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 may exist in two versions to sort data two ways: in dictionary order and in telephone-book order. Suppose your site is in France, and it uses the default French locale, and suppose the standard setup for this locale uses dictionary order. However, in this example, your site also needs to use a site-defined locale that collates data in telephone-book order. You may 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 uses 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:

Software developers who produce internationalized applications

Users who run internationalized applications on your system

There are three sources of information about worldwide support:

For a list of optional software subsets that support internationalization, see the Installation Guide.

For information about setting up and maintaining an operating system environment for programmers who write internationalized software, see the Writing Software for the International Market manual.

To set up and maintain your system for users of internationalized applications, see the System Setup graphical user interface and click on the Configuration icon and then the internationalization icon. From the internationalization window, you can select tasks to configure or modify several of the worldwide support capabilities on your system. To make this option available, you must install at least one international support software subset. You also can launch this option from the CDE Application Manager. See Chapter 1 for information on using CDE.

3.4 Customizing Your Time Zone

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 be consistent with the city of New York on the American continent:

# ln -sf /etc/zoneinfo/America/New_York /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. See zic(8) for more information on the format of the time zone database files.

You also can 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 also can 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:

EST (eastern standard time) specifies the standard time, which is 5 hours behind GMT.

EDT (eastern daylight time) specifies the daylight savings time, which is 4 hours behind GMT.

EDT starts on the first Sunday in April and ends on the last Sunday in October; the change to and from daylight savings time occurs at 2:00 A.M., which is the default time.

EST5EDT4,M4.1.0,M10.5.0

You can 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:

:America/New_York

See tzfile(4) 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 Greenwich Mean Time (GMT).

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.

See timezone(3) for more information.

3.5 Customizing Power Management

The operating system contains features that allow you to conserve power on certain systems that have the appropriate hardware. Read the system owner's manual for information on whether your system supports power management. Power management utilities allow you to:

Enable energy-saving features on supported monitors (Energy Star) and control the power modes and idle time.

Select which disks you want to spin down after a selected idle time. Some systems are delivered for use with certain energy saving capabilities enabled by default. If disk drives spin down unexpectedly or data transfer sometimes seems to take a long time, verify whether this feature is enabled.

Set the CPU power usage. This feature is available only on supported systems in which the CPU supports a slow down, power saving mode.

View and set these features on single workstations or groups of systems through the System Administration utilities or through command line interfaces. The operating system provides utilities for managing and monitoring hardware across a network of systems.

Use the Event Management (EVM) interface to monitor power management events.

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

Manage an individual workstation by using the X11-compliant graphical user interface /usr/bin/X11/dxpower utility. See the online help and dxpower(8) for information on invoking this interface.

Use sysconfig and sysconfigdb to load and set kernel attributes. See sysconfig(8) and sysconfigdb(8) for a list of command options. This method of power management will be retired in a future release.

3.5.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 be used only 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:

Click on the Application Manager icon.

Double click on the System_Admin application group icon.

Double click on the DailyAdmin application group icon.

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:

Enable or disable power management for all supported devices on the host system.

Specify the time of day when power management is enabled. For example, you can set systems to only go into power saving modes during the night.

Enable the energy-saving features of the graphics monitor, and set the minimum idle time before standby, suspend, and power-off modes are selected. For example, if a system is rarely used, you can set it to go straight to power-off mode after only a few minutes of idle time.

Enable power saving mode for each individual disk. For example, you may want to keep the boot disk in full power mode, but spin down any unused user file systems after a specified idle time to conserve power.

Caution

Monitors (displays) that do not support DPMS (Display Power Management Signaling) may be damaged by the activation of the DPMS feature. It is important that you verify the specifications for your monitor in the owner's manual. Monitors that support DPMS and are put in a power savings state 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 select Help in the lower right-hand corner of the window.

3.5.2 Using the sysconfig Command

You can control power management attributes from the command line by using the sysconfig command to manage the sysconfigdb database. For example, you need to use the sysconfig command if you activate 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.5.2.1 for descriptions of these attributes.

Caution

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

3.5.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:

default_pwrmgr_state
The global power management state. Specify 1 to enable or 0 to disable this attribute.

cpu_slowdown
The current state of CPU slowdown. Specify 1 to enable or 0 to disable this attribute.

disk_dwell_time
The default dwell time, in minutes, for registered disks.

disk_spindown
The current state of disk spindown. Specify 1 to enable or 0 to disable this attribute.

graphics_powerdown
The current state of graphics power down. Specify 1 to enable or 0 to disable this attribute.

graphics_standby_dwell
The default dwell time, in minutes, for standby Display Power Management Signaling (DPMS) mode. Specify a value of 0 to disable this attribute.
When Monitor Power Management and Screen Saver are enabled simultaneously, DPMS-capable monitors are placed in active power-off mode. In addition, on Energy-Star compliant platforms, the disk spin down feature may be activated also. While these energy-saving features are active, the X server may override them so that it can continue to run the screen saver. To minimize power consumption, stop using active screen savers by doing any of the following:
- In the Screen Saver panel of the Screen dialog box, under the Style Manager, select Blank Screen and deselect any active screen savers that may be running.
- Select Off in the same dialog box.
- Execute the xset s off command from a terminal client window.

graphics_suspend_dwell
The default dwell time, in minutes, for suspend DPMS mode. Specify 0 to disable this attribute or specify a value greater than or equal to the value for graphics_standby_dwell.

graphics_off_dwell
The default dwell time, in minutes, for off DPMS mode. Specify 0 to disable this attribute or specify a value greater than or equal to the values for graphics_standby_dwell and graphics_suspend_dwell.

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 sysconfigdb(8) for more information on using stanza files.

3.5.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 sysconfig(8) for more information on modifying system attributes.

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

3.5.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 enables a list of management actions for the selected device, one of which may be the power management application dxpower. Selecting this menu item runs dxpower on the device.

3.6 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.

Note

You may see messages implying that there is a shortage of virtual memory (vm) or processes may be killed because of an apparent lack of vm. In such cases, virtual memory does not always mean swap space, but can refer to resources required by the vm kernel subsystem.
If you do not observe any excessive use of swap space, and if you do not observe messages that specifically reference a lack of swap space, the problem may be a lack of per-process memory limits. See Section 3.6.5 for more information.

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: Reclaiming pages so they can be reused
Swapping: Writing a suspended process' modified (dirty) pages to swap space, which frees large amounts of memory

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 were not referenced previously.

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 was not recently referenced to the swap space. This operation is called modified page writing or a pageout. 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 its modified virtual pages to swap space. This operation is called a swapout. Swapouts typically occur on systems that are memory constrained.

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 the swap space allocation is insufficient, the system is unable to save a crash dump, which can contain valuable information to assist you in recovering from errors. See Chapter 12 for information on crash dump space requirements.

3.6.1 Related Documentation and Utilities

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

3.6.1.1 Related Documentation

Information on administering swap space can be found in the following manuals:

Installation Guide — Advanced Topics: Describes how to plan for initial swap space, and set up initial swap during installation of the operating system.
System Configuration and Tuning: Describes advanced concepts of virtual memory and swap, including strategies for performance tuning that involve swap space configuration.

See swapon(8) and swapon(2) for information on creating additional swap space. See Section 3.6.1.2 for the reference pages for the related utilities.

3.6.1.2 Related Utilities

The following utilities are used during swap space administration:

Utility	Path Name	Description
Disk Configuration	`/usr/sbin/diskconfig`	This graphical user interface can be used to examine disks to locate unused partitions that can be assigned to swap. See `diskconfig`(8) for information on invoking and using the utility.
Kernel Tuner	`/usr/bin/X11/dxkerneltuner`	This graphical user interface can be used to modify kernel swap attributes in the system configuration file. See `dxkerneltuner`(8) for information on invoking and using this utility.
sysconfig	`/sbin/sysconfig`	This command line interface can be used to modify kernel swap attributes in the system configuration file. See `sysconfig`(8) for information on modifying system attributes.
disklabel	`/sbin/disklabel`	This command line interface can be used to modify kernel swap attributes in the system configuration file. See `disklabel`(8) for information on labeling a disk (otherwise known as formatting disk partitions).

3.6.2 Allocating Swap Space

Initially, swap space is 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 is provided by system console warning messages, stating that available swap space is depleted. Before adding swap space, verify that any sudden lack of space is not caused by a system problem. Use the following command to ensure that runaway processes or unusual user activities are not using up swap space:

# ps agx

(Alternatively, you can examine system log and event files for swap error messages.) If the resulting list of processes looks normal, you may need to add swap space.

Swap space can be added temporarily by running the swapon command. 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:

The swapon command verifies a disk partition to ensure that you do not write over data or use overlapping partitions. If you have a choice of disks, you may 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.

Run swapon to create the swap partition, as shown in the following example:
```
# /sbin/swapon /dev/disk/dsk0b
```
You may 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
```
You can repeat step 1 to add additional partitions, if required.

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:
- Copy the current file to a temporary file name in case you need to recover it. Use a text editor to open the file, and search for the string vm:
- You observe a swapdevice= entry for the initial swap space, created during installation. Add the device special file name for the new swap partition, separating each swap device entry with a comma, as follows:
```
vm: 
              swapdevice=/dev/disk/dsk1b, /dev/disk/dsk3h
              vm-swap-eager=1
```
  The new swap partitions open automatically when the system is rebooted, or when you use the command:
```
# /sbin/swapon -a
```

See swapon(8) 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.6.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 terminates 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 to be created on your system. Immediate mode requires significantly more swap space than deferred mode because it guarantees that there is 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 to 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, use the default amount of swap space and adjust the swap space as needed, first. Consider using a swap size of about half the size of physical memory.

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 can result in one or more processes being involuntarily terminated.

For more information on virtual memory, see the System Configuration and Tuning manual.

3.6.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 the dxkerneltuner or sysconfig utility to examine kernel attribute values. You observe 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:

vm-swap-eager=1: The system is using immediate swap mode.
vm-swap-eager=0: The system is using deferred swap mode.

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

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

3.6.5 Correcting an Apparent Lack of Swap Space

There are limits on the amount of virtual memory that an individual process can use. These limits are not related to the total amount of available swap space. Consequently, you may see error messages stating that a process has run out of virtual memory even though a swap monitor, such as the dxsysinfo utility, does not display a swap shortage. In some cases, a process could be killed automatically when it exceeds its allotted virtual memory.

See the discussion for the vm_swap_eager attribute in sys_attrs_vm(5) for a description of the effect of the swap allocation mode.

Use the following command to verify that your swap space is adequate:

#  swapon -s

The data field titled In-use space: informs you if you are using most of your available swap space.

If you are not using all your available swap space but you are observing problems running large processes, you may need to assign more resources to the process. There are several kernel attributes in the proc subsystem that you can use to control the per-process virtual memory resources:

Stack limit: The per-proc-stack-size and max-per-proc-stack-size attributes.
Data limit: The per-proc-data-size and max-per-proc-data-size attributes.
Address space: The max-per-proc-address-space and per-proc-address-space attributes.

Consider the following options if you encounter problems that appear to be from a lack of memory:

See the reference page that describes your command shell, such as ksh(1). Command shells have a limit or ulimit option that enables you to modify the virtual memory resources for a process.

Use the sysconfigdb command or the Kernel Tuner GUI to modify the value of the per-process resource limits in the /etc/sysconfigtab file. Instructions for modifying kernel attributes are provided in Chapter 4.

See the System Configuration and Tuning manual for information on tuning virtual memory (vm) subsystem attributes, such as vm-maxvas. See sys_attrs(5) for more information on the system attributes.