This chapter describes how you can customize your system environment in the following areas:
System initialization files, which you use to initialize and control the system's run levels
National language directories, which you use to supply support for language-specific and country-specific programs
Internationalization features, which you tailor to support programmers and users developing and running programs for international audiences
System time zone directories and environment variables, which you use to administer local and worldwide time zone information on your system
System security tasks, which you employ to administer the security policy of your organization
Performance monitors, which you set up and use to measure diverse aspects of system performance
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)
Power manager elements, which you set up and use to control power consumption in Energy Star-compliant peripherals and processors
To define and customize the system environment, you modify certain initialization files that specify and control processes and run levels. Tru64 UNIX 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.
This section describes the Tru64 UNIX software and provides instructions
for identifying, using, and modifying the files that initialize and control
the system environment.
To understand and utilize available functionality,
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, you should 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 customized environment.
The following system files and directories influence system startup and operation:
/etc/inittabOne of the key initialization files whose entries define run levels and associated processes and administer terminals. Section 4.1.1 describes this file.
/etc/securettysA text file that marks whether a given tty line allows root logins. Section 4.1.1.7 describes this file.
/sbin/bcheckrcA system initialization run command script associated with checking and mounting file systems at startup time. Section 4.1.1.2 describes this file.
/sbin/init.dThe initialization directory that contains executable files associated with system startup and the available run levels. Section 4.1.2.1 describes the directory structure and contents.
/sbin/rcn
.dA 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 4.1.2.2,
Section 4.1.2.3, and
Section 4.1.2.4
describe the
rc
directory structure
and contents.
/sbin/rcnThe 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 4.1.2.2,
Section 4.1.2.3,
and
Section 4.1.2.4
describe the contents and use of these scripts.
/etc/rc.configA 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/sysconfigtabThe database file that contains information about the subsystems that can be dynamically configured. Chapter 5 describes this file.
/usr/sbin/gettyThe executable file that sets and manages terminal lines.
Section 4.1.1.4
and
Section 4.1.1.5
describe this program.
Refer to the
getty(8)
reference page for more information.
/etc/gettydefsThe 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 4.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/NAMEThe text file that defines the components that the system builds into your configuration. The NAME variable usually specifies the system name. Chapter 5 describes this file.
/usr/sys/conf/NAME
.listThe 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 5 describes this file.
/usr/sys/conf/param.cThe text file that contains default values for some tunable system parameters used in building the system's kernel. Chapter 5 describes this 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 Tru64 UNIX
software 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 # Dynamic loading not supported in this release. #kls:23:bootwait:/sbin/kloadsrv < /dev/console > /dev/console 2>&1 #cfg:23:wait:/sbin/cfgmgr -l < /dev/console > /dev/console 2>&1 update:23:wait:/sbin/update > /dev/console 2>&1 it:23:wait:/sbin/it < /dev/console > /dev/console 2>&1 kmk:3:bootwait:/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 lat02:3:respawn:/usr/sbin/getty /dev/tty02 lat03:3:respawn:/usr/sbin/getty /dev/tty03
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
This 14-character field uniquely identifies an object entry.
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.
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. |
bootwait |
When
init
first executes
and reads the
inittab
file, it processes this line entry.
The
init
program starts the process, waits for its termination
and, when it dies, does not restart the process. |
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.
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.
At boot time, the
init
program
looks in the
inittab
file for the
initdefault
keyword to find the definition of the run level to enter.
If there
is no entry 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:
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.
The
init
program looks in the
inittab
file for the
bootwait
entry.
In the previous
inittab
file example, the following line contains a
bootwait
entry:
kmk:3:bootwait:/sbin/kmknod > /dev/console 2>&1
In this case, the
init
program invokes the
/sbin/kmknod
script for the
kmk
entry.
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 previous example of the
inittab
file, 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
inittabfile 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'sgettyprocess.
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 Tru64 UNIX 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.
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 4.1.2.
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 pathname 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
The Tru64 UNIX
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.
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:
acct inetd motd preserve savecore syslog crashdc kloadsrv named quota sendmail uucp cron kmod nfs recpasswd settime xdm enlogin lat nfsmount rmtmpfiles sia xntpd gateway loader nis route snmpd inet lpd paging rwho startlmf
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 staff 17 Jan 04 10:31 K00enlogin -> ../init.d/enlogin lrwxr-xr-x 1 root staff 13 Jan 04 10:44 K05lpd -> ../init.d/lpd lrwxr-xr-x 1 root staff 13 Jan 04 10:51 K07lat -> ../init.d/lat lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K10inetd -> ../init.d/inetd lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K15snmpd -> ../init.d/snmpd lrwxr-xr-x 1 root staff 13 Jan 04 10:31 K19xdm -> ../init.d/xdm lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K20xntpd -> ../init.d/xntpd lrwxr-xr-x 1 root staff 14 Jan 04 10:31 K22cron -> ../init.d/cron lrwxr-xr-x 1 root staff 18 Jan 04 10:31 K25sendmail -> ../init.d/sendmail lrwxr-xr-x 1 root staff 13 Jan 04 10:41 K30nfs -> ../init.d/nfs lrwxr-xr-x 1 root staff 18 Jan 04 10:41 K35nfsmount -> ../init.d/nfsmount lrwxr-xr-x 1 root staff 13 Jan 04 10:37 K38nis -> ../init.d/nis lrwxr-xr-x 1 root staff 15 Jan 04 10:41 K40named -> ../init.d/named lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K42rwho -> ../init.d/rwho lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K43route -> ../init.d/route lrwxr-xr-x 1 root staff 17 Jan 04 10:37 K44gateway -> ../init.d/gateway lrwxr-xr-x 1 root staff 16 Jan 04 10:31 K45syslog -> ../init.d/syslog lrwxr-xr-x 1 root staff 14 Jan 04 10:52 K46uucp -> ../init.d/uucp lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K50inet -> ../init.d/inet lrwxr-xr-x 1 root staff 15 Jan 04 10:31 K52quota -> ../init.d/quota
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 since the numbers
are sorted and the commands are run in ascending order.
See the
rc0(8)
reference page for additional information.
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 staff 13 Jan 04 10:44 K00lpd -> ../init.d/lpd lrwxr-xr-x 1 root staff 13 Jan 04 10:51 K03lat -> ../init.d/lat lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K05inetd -> ../init.d/inetd lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K10snmpd -> ../init.d/snmpd lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K15xntpd -> ../init.d/xntpd lrwxr-xr-x 1 root staff 14 Jan 04 10:31 K20cron -> ../init.d/cron lrwxr-xr-x 1 root staff 18 Jan 04 10:31 K30sendmail -> ../init.d/sendmail lrwxr-xr-x 1 root staff 13 Jan 04 10:41 K35nfs -> ../init.d/nfs lrwxr-xr-x 1 root staff 18 Jan 04 10:41 K40nfsmount -> ../init.d/nfsmount lrwxr-xr-x 1 root staff 13 Jan 04 10:37 K43nis -> ../init.d/nis lrwxr-xr-x 1 root staff 15 Jan 04 10:41 K45named -> ../init.d/named lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K47rwho -> ../init.d/rwho lrwxr-xr-x 1 root staff 15 Jan 04 10:37 K48route -> ../init.d/route lrwxr-xr-x 1 root staff 17 Jan 04 10:37 K49gateway -> ../init.d/gateway lrwxr-xr-x 1 root staff 16 Jan 04 10:31 K50syslog -> ../init.d/syslog lrwxr-xr-x 1 root staff 14 Jan 04 10:52 K51uucp -> ../init.d/uucp lrwxr-xr-x 1 root staff 14 Jan 04 10:37 K55inet -> ../init.d/inet lrwxr-xr-x 1 root staff 15 Jan 04 10:31 K57quota -> ../init.d/quota lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S00savecore -> ../init.d/savecore lrwxr-xr-x 1 root staff 16 Jan 04 10:31 S05paging -> ../init.d/paging lrwxr-xr-x 1 root staff 19 Jan 04 10:31 S10recpasswd -> ../init.d/recpasswd lrwxr-xr-x 1 root staff 14 Jan 04 10:52 S15uucp -> ../init.d/uucp lrwxr-xr-x 1 root staff 17 Jan 04 10:31 S25enlogin -> ../init.d/enlogin
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 since the numbers are sorted and the commands are run in ascending
order.
Refer to the
rc2(8)
reference page for more information.
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 staff 14 Jan 04 10:37 S00inet -> ../init.d/inet lrwxr-xr-x 1 root staff 15 Jan 04 10:31 S01quota -> ../init.d/quota lrwxr-xr-x 1 root staff 14 Jan 04 10:52 S04uucp -> ../init.d/uucp lrwxr-xr-x 1 root staff 17 Jan 04 10:31 S05settime -> ../init.d/settime lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S08startlmf -> ../init.d/startlmf lrwxr-xr-x 1 root staff 16 Jan 04 10:31 S10syslog -> ../init.d/syslog lrwxr-xr-x 1 root staff 17 Jan 04 10:37 S11gateway -> ../init.d/gateway lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S12route -> ../init.d/route lrwxr-xr-x 1 root staff 14 Jan 04 10:37 S13rwho -> ../init.d/rwho lrwxr-xr-x 1 root staff 15 Jan 04 10:41 S15named -> ../init.d/named lrwxr-xr-x 1 root staff 13 Jan 04 10:37 S18nis -> ../init.d/nis lrwxr-xr-x 1 root staff 18 Jan 04 10:41 S20nfsmount -> ../init.d/nfsmount lrwxr-xr-x 1 root staff 16 Jan 04 10:31 S22loader -> ../init.d/loader lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S23kloadsrv -> ../init.d/kloadsrv lrwxr-xr-x 1 root staff 14 Jan 04 10:31 S24kmod -> ../init.d/kmod lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S25preserve -> ../init.d/preserve lrwxr-xr-x 1 root staff 13 Jan 04 10:31 S26sia -> ../init.d/sia lrwxr-xr-x 1 root staff 20 Jan 04 10:31 S30rmtmpfiles -> ../init.d/rmtmpfiles lrwxr-xr-x 1 root staff 13 Jan 04 10:41 S35nfs -> ../init.d/nfs lrwxr-xr-x 1 root staff 18 Jan 04 10:31 S40sendmail -> ../init.d/sendmail lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S45xntpd -> ../init.d/xntpd lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S50snmpd -> ../init.d/snmpd lrwxr-xr-x 1 root staff 15 Jan 04 10:37 S55inetd -> ../init.d/inetd lrwxr-xr-x 1 root staff 14 Jan 04 10:31 S57cron -> ../init.d/cron lrwxr-xr-x 1 root staff 13 Jan 04 10:30 S58lat -> ../init.d/lat lrwxr-xr-x 1 root staff 14 Jan 04 10:30 S60motd -> ../init.d/motd lrwxr-xr-x 1 root staff 13 Jan 04 10:44 S65lpd -> ../init.d/lpd lrwxr-xr-x 1 root staff 14 Jan 04 10:42 S75acct -> ../init.d/acct lrwxr-xr-x 1 root staff 17 Jan 04 10:30 S80crashdc -> ../init.d/crashdc lrwxr-xr-x 1 root staff 13 Jan 04 10:30 S95xdm -> ../init.d/xdm
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 since the numbers are sorted and the commands are run
in ascending order.
Refer to the
rc3(8)
reference page for more information.
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. 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]
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.
This file should
be monitored to prevent it from becoming excessively large.
Refer to the
crontab(1)
reference page for more information.
Tru64 UNIX 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, which 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, which contain translations of messages used
by programs.
These files reside in the
/usr/lib/nls/msg/locale-name
directory.
Table 4-1
lists 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.
| 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 |
| French_Switzerland | fr_CH.ISO8859-1 |
| German_Belgium | de_BE.ISO8859-1 |
| German_Germany | de_DE.ISO8859-1 |
| German_Switzerland | de_CH.ISO8859-1 |
| Greek-Greece | el_GR.ISO8859-7 |
| Italian-Italy | it_IT.ISO8859-1 |
| Norwegian-Norway | no_NO.ISO8859-1 |
| Portuguese-Portugal | pt_PT.ISO8859-1 |
| Spanish-Spain | es_ES.ISO8859-1 |
| Swedish-Sweden | sv_SV.ISO8859-1 |
| Turkish-Turkey | tr_TR.ISO8859-1 |
Note
The
/usr/lib/nls/locdirectory 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 4-1. These tables and variants are provided only to ensure system compatibility for old programs and should not be used by new applications.
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 mentioned in Table 4-1 is the system default. The C locale specifies U.S. English and uses the 7-bit ASCII codeset. The main difference between the
Clocale 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:
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.
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 4-2 describes the environment variables that influence locale categories.
| 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 all of the category variables locale names. 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.
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.
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:
Tru64 UNIX is an internationalized operating system. Your site's 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
The Tru64 UNIX product provides three sources of information about worldwide support:
For a list of optional software subsets that support internationalization, see the Tru64 UNIX Installation Guide.
For information about setting up and maintaining an operating system environment for programmers who write internationalized software, see the Tru64 UNIX manual Writing Software for the International Market.
To set up and maintain your system for users of internationalized applications, see the SysMan graphical 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.
Information about configuring your system's time zone is in Chapter 5. 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:
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 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.
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 (+).
Specifies when daylight savings time starts and ends. The start and end variable has the following syntaxes:
JjnMm.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.
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, which is the default time.
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 5 for information about configuring a time zone for your system.
The system security tasks of the administrator range from the protection of physical components of the system and its environment to the implementation of an organization's security policies.
Two manuals in the Tru64 UNIX documentation set describe security-related tasks. Refer to the following documents for information about administering local system security:
The Technical Overview briefly describes the security components of the Tru64 UNIX operating system.
The Security manual is the principal source of security-related information for Tru64 UNIX users, administrators, and programmers dealing with the security components. Use this manual to administer security on an Tru64 UNIX operating system.
The following sections discuss how you set up and use some of the performance monitoring components of the Tru64 UNIX operating system:
Monitoring Performance History
Performance Monitor
Performance Manager
X-windows graphical interfaces.
Tru64 UNIX performance monitoring commands and scripts
The
sys_check
utility
The Monitoring Performance History (MPH) utility gathers timely and accurate information on the reliability and availability of the Tru64 UNIX operating system and its hardware environment.
MPH is a suite of shell scripts that copy error log and crash dump information twice per week. The information is automatically copied to Compaq for analysis via Internet Mail. After analysis, reports are generated and distributed to the users of this information, namely Software and Hardware Engineering, Manufacturing, and Compaq Services. This data is internally secure to Compaq and will be used exclusively for monitoring purposes.
The MPH process is automatic, requiring no human intervention and no training. The installation time is approximately 10 minutes.
This software will not impact or degrade your system's performance. MPH runs as a background task, using very negligible CPU resources and is invisible to the user. The disk space required for the collected data and the application is approximately 300 blocks per system. This could be slightly higher in the case of a high number of errors.
Before running MPH, review the following information:
The Software Development Environment subset (OSFPGMR) must be installed.
The MPH software kit is contained in the mandatory base software
subset OSFHWBASE400.
This subset is installed automatically
during the operating system installation.
Full documentation is located in
/usr/field/mph/user_guide*.
Disk space requirements for MPH is approximately 100 blocks.
If the operating system needs to be shut down for any reason, an orderly shutdown process must be followed. Otherwise, you will have to restart the MPH script.
To run MPH on your system, complete the following steps:
Enter the following command to run the MPH script:
#MPH_OSF_020.CSH
Enter the information requested by the script.
Running the
MPH_OSF_020.CSH
script does the following:
Creates an MPH directory.
The default directory location
is
/var/mph.
Updates the system
crontab
files to execute
the MPH files at the appropriate times.
The binary error log extractor runs
daily at 2:00 a.m.
The data is mailed to Compaq at 3:00 a.m.
every
Wednesday and Sunday.
The Performance Monitor is a real-time performance monitor that allows you to detect and correct performance problems. You can display graphs and counters to monitor dozens of different system values, including CPU performance, memory usage, disk transfers, file-system capacity, network efficiency, and buffer cache hit rates. In addition, thresholds can be set to alert you to, or correct, a problem when it occurs, and archives of data can be kept for high-speed playback or compression into charts, showing resource usage trends.
The Performance Monitor is an optional subset in the Tru64 UNIX software kit. For information about establishing and using the Performance Monitor, see the Performance Monitor User's Guide.
Performance Manager is a real-time performance monitor that allows users to detect and correct performance problems. Graphs and charts can show hundreds of different system values, including CPU performance, memory usage, disk transfers, file-system capacity, and network efficiency. Thresholds can be set to alert you to correct a problem when it occurs, commands can be run on multiple nodes from the graphical user interface, and archives of data can be kept for high-speed playback or long-term trend analysis.
A new maintenance release of Performance Manager, Version 4.0D, is included with this release and includes the following enhancements:
Dash node name support
FDDI network support
Support for TruCluster Software Products Version 1.5 configurations
Documentation available in Adobe Acrobat (pdf) format
If you are upgrading from any of the Version 2.x releases, you will also benefit from the following enhancements that were introduced in Version 4.0B:
More features for the graphical user interface, including a toolbar
Support for monitoring thresholds that have been exceeded for specified metrics
Support for invoking commands and user-supplied scripts once a threshold has been crossed
More system management and thresholding scripts
Performance analysis, system management scripts, and cluster analysis
Per-process and per-thread metrics
Oracle7 database support
The release notes for Performance Manager are included on the Associated Products, Volume 2 CD-ROM. The PostScript file is PMGR***_RELNOTES.ps and the text file is PMGR***_RELNOTES.txt.
Several graphical tools are provided for fast checking of one or more aspects of system performance. These are X-based utilities that will display under any X-compliant windowing interface. Under the Common Desktop Environment, (CDE) the interfaces are organized under the Tool Drawer icon, on the CDE front panel. This icon displays the Application_Manager folder, which contains monitoring tools in the following sub-folders:
Desktop_Tools - This folder contains simple interfaces such as System Load to monitor CPU usage or Disk Usage to obtain the current status of the file system space per disk.
System_Admin - This folder provides two sub-folders that contain tools useful for monitoring:
MonitoringTuning - Contains graphical interfaces such
as the process tuner,
proctuner
and the kernel tuner
dxkerneltuner
that are useful for checking and changing system settings.
Tools - contains graphical interfaces to command-line
utilities such as
iostat
and
netstat
that enable you to constantly monitor the output, setting your preferences
for update and display.
As with any graphical application, you can place the icons on the System
Administration Desktop for quick access to system information or keep the
displays open constantly to monitor any aspect of system performance.
Executables
for the graphical interfaces are located in
/usr/bin/X11.
The
sys_check
tool is used to produce an extensive
dump of system performance parameters.
It enables you to record many system
values and parameters, providing a useful baseline of system data.
This may
be particularly useful before you undertake major changes or perform troubleshooting
procedures.
The
sys_check
can optionally produce an HTML document
on standard output.
Used with the
-escalate, flag the
script produces a
/var/tmp/escalate*
output files by default.
These files can be escalated to your technical support site and used for diagnosing
system problems and errors.
Use the following command to obtain a complete
list of options:
#/usr/sbin/sys_check -h
Note that the output produced by
sys_check
typically varies between 0.5MB and 3MB in size and it can take from 30 minutes
to an hour to complete the check.
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:
Plan the allocation of CPU resources
Use
class_admin
to set up and maintain
the class database
Create classes and add members to the classes
Verify class entries using the
show
command
Save the entries to the database
Enable Class Scheduling to start the daemon
You use the Class Scheduler commands to monitor and control scheduling as follows:
Execute
class_admin
commands such as
stat
from the command line or a shell script without running an
interactive session
Use the
runclass
command to execute a task
according to the priorities set for a particular class
Note that it is not be necessary to perform tasks in the preceding specific sequence. To resolve a resource sharing problem quickly, you can simply execute a series of class_admin commands at the command line to configure a default database, add classes and class members, and enable the class scheduling daemon. The following sections suggest a systematic approach to using class scheduling, although you can use it equally well to create a quick fix to a CPU resource sharing problem.
The following reference pages contain detailed information on using the Class Scheduler commands and options:
class_scheduling(4)
class_admin(8)
runclass(1)
classcntl(2)
Enter the following command to obtain on-line help for
class_admin:
#/usr/sbin/class_admin help
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:
UID - user identifier, a unique number assigned to each user account (login).
GID - group identifier, a number or name assigned to several user accounts to indicate that they belong to the same group.
PID - process identifier.
PGID - process group identifier
SESS - session identifier
Note that process identifiers that are temporary, such as a PID, do not persist across a reboot and cease 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:
Execute a task (process) according to the CPU access value
set for a specific class using
runclass
.
For example,
you might set a value for interactive operations that is much higher than
background processes such as print daemons.
To temporarily use the higher
value for a print job, you can execute the
lpr
command
in the same class as interactive operations.
Execute class scheduling commands from within scripts using
the command line version of
class_admin.
The following utilities are also available for use when monitoring and tuning processes:
The
nice
and
renice
commands
The
iostat
and
vmstat
commands
The Process Tuner (dxproctuner) graphical
interface, available from the CDE MonitoringTuning folder in the Application
Manager - System_Admin.
Refer to the online help for more information on using
this interface.
Refer also to the System Configuration and Tuning guide for more information on tuning options.
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. Alternatively, if there are critical real-time tasks that should take precedence over interactive processes such as process control applications, you may want to assign more resources to real-time tasks. Compaq recommends that you design a baseline, assigning processes to classes and then monitor processes and user feedback to tune the database by moving tasks from class to class or changing the CPU access time of the classes.
Use the
class_admin
command to configure an initial
database.
This command provides:
An interactive command with sub commands that enable you to
create and administer a database of classes.
The database is stored in the
binary file
/etc/class, which cannot be edited manually.
Type
help
at the
class>
command prompt
for a list of options.
A command mode that allows you to execute
class_admin
commands at the command prompt, or include commands in shell scripts.
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_adminClass 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]:yesEnforce class scheduling when the CPU is otherwise idle? (yes/no) [no]:yesHow often do you want the system to reset class usage? Enter number of seconds (1):2class>
The configuration values have the following effect:
To be scheduled, a process must be assigned to a class.
If
you answer
yes
to the first prompt, a special class called
the
default
class is created.
Any process that has not
been explicitly assigned to a defined class will be assigned to the default
class.
If you answer
no
to this prompt, then only those
processes which are explicitly assigned to a defined class will be class scheduled.
If you answer
yes
to the second prompt,
you allow classes to exceed their allotted CPU time percentage when the system
is otherwise idle.
If you answer
no
, classes are restricted
to their allotted percentage even if the CPU has no other work.
The third prompt allows you to set the standard reset time for all classes. For example, if you choose the short default time of 1 second, each class will have more frequent, but shorter opportunities to access the CPU.
Use a small number (several seconds) if there are interactive jobs subject to class scheduling to give them a quick response time. If only batch jobs are class scheduled, response time is not an issue and larger values may be used.
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>showConfiguration: -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.
When the database has been configured, you can administer classes as follows:
Create a class:
Add processes to the class
Delete processes from a class
Change the CPU access value (time percentage) of any class
Destroy an entire class, whether empty or populated
Show details of class members and configuration settings
View statistics of actual CPU use against current priority settings
Some of these options are described briefly in the following sections. For detailed descriptions of command options, refer to the help and reference pages.
To create a class, either use the command mode or enter an interactive session as follows:
#class_adminclass>create high_users 50
The command mode version is entered as follows:
#class_admin create batch_jobs 10batch_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>quitClass scheduler database modified. Save changes? (yes/no) [yes]:yeschanges saved
Members of a class are identified by any one of five identifiers assigned to processes by the system. You specify one of these identifiers when assigning a process to a class.
Once you have created classes, you can add processes to one or more
classes by specifying the ownership of the processes (using the UIDs and GIDs)
with 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.
Individual processes can be added using process identifiers 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 for processes.
Using the following command, you can display the PID
for every process running on the system:
#/sbin/ps ajUSER PID PPID PGID SESS JOBC S TTY TIME COMMAND wal 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 allowed:
gid - A group identification number from the
/etc/group
file.
This number will add all resource users that are
assigned that number.
uid - A user identification number from the
/etc/passwd
file.
This number will add only the specific resource
user to which the UID is assigned.
pgrp - A process group identifier from the
ps aj
command.
See the entries under the
PGID
table heading
session - A session identifier from the
ps
aj
command.
See the entries under the
SESS
table
heading
pid - The process identifier from the
ps aj
command.
See the entries under the PID table heading.
You will probably use ownership identifiers
uid
and
gid
most often in your established classes, as these identifiers
will persist across a reboot or when class scheduling is stopped and restarted.
Individual process identifiers will not persist across a reboot.
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.
To enable the class scheduler daemon, you execute the following command:
#class_admin enableClass scheduling enabled and daemon /usr/sbin/class_daemon started.
To disable the daemon, enter the following command:
#class_admin disableClass scheduling disabled.
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 235uid 234 457 235 added to high_users
In command mode, additions to a class are automatically saved to the
/etc/class
database.
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 11uid 11 deleted from high_users
This
example deletes the single UID number 11 from class
high_users.
Consult the
class_admin(8)
reference page for information on
the following options:
Change the priority of a class. For example:
class>change batch_jobs 20batch_jobs retargeted at 20%
Destroy an entire class, whether empty or full. For example:
class>destroy high_usershigh_users is not empty. to destroy anyway? [yes/no]:yeshigh_users destroyed
Loading and saving scheduling databases. For example:
class>load database_performancecurrent database modified and not saved load new database anyway (destroys changes)? (yes/no) [yes]:yesdatabase database_performance loaded
In this example the presence of unsaved modifications to the current database was detected, and the user was prompted to save the changes.
View statistics of actual CPU use against current priority settings. For example:
class>statsClass scheduler status: enabled class name target percentage actual percentage high_users 50% 40.0% batch_jobs 10% 2.0%
Once you have established scheduler classes and enabled class scheduling,
you can use the
runclass
command to execute a command in
a particular class.
You must have root privileges to use this command only
if you want a higher CPU percentage than is currently assigned to you.
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.
Use the
dxpower
utility, the
sysconfig
command, and
sysconfigdb
database to manage power-saving
features on hardware subsystems, such as processors and peripherals, that
employ power management capabilities.
With these utilities, you enable power
management modes and specify the amount of time to wait before shutting off
each component in order to save power.
Consult the hardware documentation for any display monitor (screen) that is attached to your system before implementing power management.
Warning - Monitors (screens) that do not support Power Management
Monitors (display screens) that do not support DPMS (Display Power Management Signaling) can be damaged if the DPMS signal is activated. Consult the hardware documentation that came with your monitor, or telephone the manufacturer if you do not have documentation.
The time it takes a DPMS-compatible monitor to come out of a power-saving
state depends on the monitor.
You will observe that the longer the monitor
is in the 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.
In addition,
there are some monitors (for example, the VRC21-HX) that turn off the Power
LED (display light) when they enter the
DPMS_OFF
state.
Moving the mouse or typing at the keyboard will not bring the display back.
Only by pressing the power switch off, then on again, will mouse and keyboard
activity cause the display to return.
Because of the varying behavior of monitors
when in certain DPMS states, you should read your monitor specification to
find out about the expected behavior and other visual features while in each
power-savings state.
If you have CDE installed on your system, 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 not using CDE, 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 scales you use to specify dwell
times.
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.
You can control power management attributes from the command line by
using
sysconfig
commands to manage the
sysconfigdb
database.
For example, you will need to use these commands 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 4.8.3.1
for descriptions of
these attributes.
Caution
Do not attempt to use the
sysconfigcommands anddxpowersimultaneously. If you do, you could encounter unpredictable behavior.
Some power management attributes, such as
disk_spindown
are enabled by default and can be reviewed using
dxpower
or by entering the following command at a terminal:
#sysconfig -q pwrmgr
Note
If you observe NOT READY errors in the system error log, the problem may be due to the disk spin-down status rather than a problem with the drive. Consider adjusting the idle time for the drive.
To change the power management values that take effect every time you
restart the kernel, you create a file in stanza file format.
See
stanza(4)
for more information.
The stanza-formatted 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 powerdown. 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.
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 the
sysconfigdb(8)
reference page for more information.
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 Display power management Signalling
modes and values in the X Server.