![[Return to Library]](BOOKSHLF.GIF)
![[TOC]](TOC.GIF)
![[PREV]](REW.GIF)
![[NEXT]](FF.GIF)
![[INDEX]](INDEX.GIF)
![[Help]](HELP.GIF)
To run a system exerciser, you must be logged in as superuser and /usr/field must be your current directory.
The commands that invoke the system exercisers provide a flag for specifying
a file where diagnostic output is saved when the exerciser completes its task.
Most of the exerciser commands have an online help flag that displays
a description of how to use that exerciser. To access online help, use the -h flag with a command. For example, to access help for the diskx exerciser, use the following command:
The exercisers can be run in the foreground or the background and can
be canceled at any time by pressing Ctrl/C in the foreground. You can run
more than one exerciser at the same time; keep in mind, however, that the
more processes you have running, the slower the system performs. Thus, before
exercising the system extensively, make sure that no other users are on the
system.
There are some restrictions when you run a system exerciser over an
NFS link or on a diskless system. For exercisers such as fsx
that need to write to a file system, the target file system must be writable
by root. Also, the directory from which an exerciser is executed must be
writable by root because temporary files are written to the directory.
These restrictions can be difficult to adhere to because NFS file systems
are often mounted in a way that prevents root from writing to them. Some
of the restrictions may be adhered to by copying the exerciser into another
directory and then executing it.
Each time an exerciser is invoked, a new log file is created in the /usr/field directory. For example, when you execute the fsx command for the first time, a log file named #LOG_FSX_01 is created. The log files contain records of each exerciser's results
and consist of the starting and stopping times, and error and statistical
information. The starting and stopping times are also logged into the default
system error log file, /var/adm/binary.errlog. This file
also contains information on errors reported by the device drivers or by the
system.
The log files provide a record of the diagnostics. However, after reading
a log file, you should delete it because an exerciser can have only nine log
files. If you attempt to run an exerciser that has accumulated nine log files,
the exerciser tells you to remove some of the old log files so that it can
create a new one.
If an exerciser finds errors, you can determine which device or area
of the system has the difficulty by looking at the /var/adm/binary.errlog file, using either the dia command (preferred)
or the uerf command. For information on the error logger,
see the Section 14.2.
For the meanings of the error numbers and signal numbers,
see the
fsx[-fpath] [-h] [-ofile] [-pnum] [-tmin]
You can specify one or more of the following flags:
The following example of the fsx command tests the /usr file system with five fsxr processes running
for 60 minutes in the background:
The files that you need to run the memx exerciser
include the following:
The memx command is restricted
by the amount of available swap space. The size of the swap space and the
available internal memory determine how many processes can run simultaneously
on your system. For example, if there are 16 MB of swap space and 16 MB of
memory, all of the swap space will be used if all 20 initiated processes (the
default) run simultaneously. This would prevent execution of other process.
Therefore, on systems with large amounts of memory and small amounts of swap
space, you must use the -p or -m flag, or
both, to restrict the number of memx processes or to restrict
the size of the memory being tested.
The memx command has the following syntax:
memx-s [-h] [-msize] [-ofile] [-pnum] [-tmin]
You can specify one or more of the following flags:
The following example of the memx command initiates
five memxr processes that test 4095 bytes of memory and
runs in the background for 60 minutes:
Using shmx, you can test the number and the size
of memory segments and shmxb processes. The shmx exerciser runs until the process is killed or until the time
specified by the -t flag is exhausted.
You automatically invoke the shmx exerciser when
you start the memx exerciser, unless you specify the memx command with the -s flag.
You
can also invoke the shmx exerciser manually. The shmx command has the following syntax:
/usr/field/shmx[-h] [-ofile] [-v] [-ttime] [-msize] [-sn]
The shmx command flags are as follows:
The following example tests the default number of memory segments, each
with a default segment size:
The following example runs three memory segments of 100,000 bytes for
180 minutes:
The diskx command has the following syntax:
diskx[flags] [parameters] -f devname
The -f devname flag specifies
the device special file on which to perform testing. The devname variable specifies the name of the block or character special
file that represents the disk to be tested. The file name must begin with
an r (for example, rz1). The last character of the file
name can specify the disk partition to test.
If a partition is not specified, all partitions are tested. For example,
if the devname variable is /dev/rra0,
all partitions are tested. If the devname variable
is /dev/rra0a, the a partition is tested.
This parameter must be specified and can be used with all test flags.
The following flags specify the tests to be run on disk:
The range of transfer sizes is divided by the number specified with
the perf_splits parameter to obtain a transfer size increment.
For example, if the perf_splits parameter is set to 10,
tests are run starting with the minimum transfer size and increasing the transfer
size by 1/10th of the range of values for each test repetition. The last transfer
size is set to the specified maximum transfer size.
If you do not specify a number of transfers, the transfer count is set
to allow the entire partition to be read or written. In this case, the transfer
count varies, depending on the transfer size and the partition size.
The performance test runs until completed or until interrupted; the
time is not limited by the -minutes parameter. This
test can take a long time to complete, depending on the test parameters.
To achieve maximum throughput, specify the -S
flag to cause sequential transfers. If the -S flag
is not specified, transfers are done to random locations. This may slow down
the observed throughput because of associated head seeks on the device.
This test is useful for generating system I/O activity. Because it
is a read-only test, you can run more than one instance of the exerciser on
the same disk.
This test performs the following operations using a range of transfer
sizes; a single transfer size is used if the -F attribute
is specified:
The following flags modify the behavior of the test:
In addition to the flags, you can also specify test parameters. You
can specify test parameters on the diskx command line or
interactively with the -i flag. If you do not specify
test parameters, default values are used.
To use a parameter, specify the parameter name, a space, and the numeric
value. For example, you could specify the following parameter:
You can use the following scaling factors:
For example, 10K would specify 10,240 bytes, and -perf_min
10K causes transfers to be done in sizes of 10,240 bytes.
You can specify one or more of the following parameters:
Specify transfer sizes to the character special file in multiples of
512 bytes. If the specified transfer size is not an even multiple, the value
is rounded down to the nearest 512 bytes. This parameter can be used with
the -r and -w test flags.
The following example performs read-only testing on the character device
special file that /dev/rrz0 represents. Because a partition
is not specified, the test reads from all partitions. The default range of
transfer sizes is used. Output from the exerciser program is displayed on
the terminal screen:
The following example runs on the a partition of /dev/rz0, and program output is logged to the diskx.out file. The program output level is set to 10 and causes additional
output to be generated:
The following example shows that performance tests are run on the a partition of /dev/rz0, and program output is
logged to the diskx.out file. The -S
flag causes sequential transfers for the best test results. Testing is done
over the default range of transfer sizes:
The following command runs the read test on all partitions of the specified
disks. The disk exerciser is invoked as three separate processes, which generate
extensive system I/O activity. The command shown in this example can be used
to test system stress:
Some tapex flags perform specific tests (for example,
an end-of-media (EOM) test). Other flags modify the tests, for example, by
enabling caching.
The tapex command has the following syntax:
tapex[flags] [parameters]
You can specify one or more of the flags described in Table 14-1.
In addition to flags, you can also specify test parameters. You specify parameters
on the tapex command line or interactively with the -i flag. If you do not specify test parameters, default values
are used.
To use a test parameter, specify the parameter name, a space, and the
number value. For example, you could specify the following parameter:
Note that you can use the following scaling factors:
For example, 10K would specify 10,240 bytes.
The following parameters can be used with all tests:
The following parameters can be used with the -a
flag, which measures performance:
14.1 Using the System Exercisers
The Digital UNIX system provides a set of exercisers that you can use
to troubleshoot your system. The exercisers test specific areas of your system,
such as file systems or system memory. This chapter explains how to use the
exercisers by addressing the following topics:
In addition to the
exercisers documented in this chapter, your system might also support the
DEC Verifier and Exerciser Tool (VET), which provides a similar set of exercisers.
With the release of Digital UNIX Version 4.0, VET is no longer present on
the installation kit as an optional subset. Instead, VET software is on the Digital UNIX
Firmware CD-ROM.
14.1.1 Running System Exercisers
# diskx -h
14.1.2 Using Exerciser Diagnostics
When an exerciser is halted (either by pressing Ctrl/C
or by timing out), diagnostics are displayed and are stored in the exerciser's
most recent log file. The diagnostics inform you of the test results.intro(2) and sigvec(2) reference pages.
14.1.3 Exercising a File System
Use the fsx command to exercise the
local file systems. The fsx command exercises the specified
local file system by initiating multiple processes, each of which creates,
writes, closes, opens, reads, validates, and unlinks a test file of random
data. For more information, see the fsx(8) reference page.Note
The fsx command has the following syntax:
# fsx -p5 -f/usr -t60 &
14.1.4 Exercising System Memory
Use the memx command to exercise the system memory.
The memx command exercises the system memory by initiating
multiple processes. By default, the size of each process is defined as the
total system memory in bytes divided by 20. The minimum allowable number
of bytes per process is 4095. The memx command runs 1s
and 0s, 0s and 1s, and random data patterns in the allocated memory being
tested.
For more information, see the memx(8) reference page
# memx -m4095 -p5 -t60 &
14.1.5 Exercising Shared Memory
Use
the shmx command to exercise the shared memory segments.
The shmx command spawns a background process called shmxb. The shmx command writes and reads the shmxb data in the segments, and the shmxb process
writes and reads the shmx data in the segments.
# shmx &
# shmx -t180 -m100000 -s3 &
14.1.6 Exercising a Disk Drive
Use the diskx command to exercise
the disk drives. The main areas that are tested include the following:
Caution
You can use the diskx command flags to specify
the tests that you want performed and to specify the parameters for the tests.
For more information, see the diskx(8) reference page.
disktab(4) reference page for more information.
The data read from the disk is examined to verify it. Then,
if random transfer testing has not been disabled (using the -S attribute), writes are issued to random locations on the partition.
After the random writes are completed, reads are issued to random locations
on the partition. The data read from random locations is examined to verify
it.
For example 10K would specify 10,240 bytes.
-perf_min 512
# diskx -f /dev/rrz0 -r
# diskx -f /dev/rz0a -o diskx.out -d -debug 10
# diskx -f /dev/rz0a -o diskx.out -p -S
# diskx -f /dev/rrz0 -r &; diskx -f /dev/rrz1 -r &; diskx -f /dev/rrz2 -r &
14.1.7 Exercising a Tape Drive
Use the tapex
command to exercise a tape drive. The tapex command writes,
reads, and validates random data on a tape device from the beginning-of-tape
(BOT) to the end-of-tape (EOT). The tapex command also
performs positioning tests for records and files, and tape transportability
tests. For more information, refer to the tapex(8) reference page.
-min_rs 512
Other parameters are restricted for use with specific tapex flags. Option-specific parameters are documented in Table 14-1.
The following example runs an extensive series of tests on tape device rmt1h and sends all output to the tapex.out file:
# tapex -f /dev/rmt1h -E -o tapex.out
The following example performs random record size tests and outputs information in verbose mode. This test runs on the default tape device /dev/rmt0h, and the output is sent to the terminal screen.
# tapex -g -v
The following example performs read and write record testing using record sizes in the range 10K to 20K. This test runs on the default tape device /dev/rmt0h, and the output is sent to the terminal screen.
# tapex -r -min_rs 10k -max_rs 20k
The following example performs a series of tests on tape device /dev/rmt0h, which is treated as fixed block device in which record sizes for tests are multiples of the blocking factor 512 KB. The append-to-media test is not performed.
# tapex -f /dev/rmt0h -fixed 512 -no_overwrite
The lines you exercise must have a loopback connector attached to the
distribution panel or the cable. Also, the line must be disabled in the /etc/inittab file and in a nonmodem line; that is, the CLOCAL flag must be set to on. Otherwise, the cmx
command repeatedly displays error messages on the terminal screen until its
time expires or until you press Ctrl/C. For more information, refer to the
You cannot test pseudodevice lines or lta device
lines. Pseudodevices have p, q, r, s, t, u, v, w, x, y,
or z as the first character after tty,
for example, ttyp3.
The cmx command has the following syntax:
/usr/field/cmx[-h] [-o file] [-t min] [-l line]
The cmx command flags are as follows:
The following example exercises communication lines tty22
and tty34 for 45 minutes in the background:
The following example exercises lines tty00 through tty07 until you press Ctrl/C:
The log files that the system and binary event-logging
facilities create have the default protection of 640, are owned by root, and belong to the system group. You must
have the proper authority to examine the files.
The following sections describe the event-logging facilities.
When you install your Digital UNIX operating system, the /etc/syslog.conf file is created and specifies the default event-logging configuration.
The /etc/syslog.conf file specifies the file names that
are the destination for the event messages, which are in ASCII format. Section 14.3.1.1 discusses the /etc/syslog.conf
file.
The binary event-logging facility uses the binlogd
daemon to collect various event-log records. The binlogd
daemon logs these records to a local file or forwards the records to a remote
system, as specified in the /etc/binlog.conf default configuration
file, which is created when you install your Digital UNIX system.
With Digital UNIX Version 4.0, the event management utility of choice
is the DECevent component, in place of the uerf error logging
facility. You can examine the binary event-log files by using the dia command (preferred) or by using the uerf
command. Both commands translate the records from binary format to ASCII format.
The DECevent utility is an event managment utility that you can use
to produce ASCII reports from entries in the system's event log files. The
DECevent utility can be used from the command line and it can be run by selecting
it from the System Management Utilities menu box.
For information about administering the DECevent
utility, see the following Digital UNIX documentation:
To enable system and binary event-logging, the special files must exist
and the event-logging daemons must be running. Refer to Section 14.3.2
and Section 14.3.3 for more information.
The following sections describe how to edit the configuration files.
The following is an example of the default /etc/syslog.conf file:
Each /etc/syslog.conf file entry has the following
entry syntax:
The syslogd daemon
ignores blank lines and lines that begin with a number sign (#). You can
specify a number sign (#) as the first character in a line to include comments
in the /etc/syslog.conf file or to disable an entry.
The facility and severity level are separated from the destination by
one or more tabs.
You can specify more than one facility and its severity level by separating
them with semicolons. In the preceding example, messages from the auth facility of crit severity level and higher
and messages from the syslog facility of debug severity level and higher are logged to the /var/adm/syslog.dated/syslog.log file.
You can specify more than one facility by separating them with commas.
In the preceding example, messages from the mail and lpr facilities of debug severity level and higher
are logged to the /var/adm/syslog.dated/misc.log file.
You can specify the following facilities:
14.1.8 Exercising the Terminal Communication System
Use the cmx command to exercise the terminal communications system. The cmx command writes, reads, and validates random data and packet
lengths on the specified communications lines.cmx(8)
reference page.
# cmx -l 22 34 -t45 &
# cmx -l 00-07
14.2 Understanding the Event-Logging Facilities
The Digital UNIX operating system uses two mechanisms to log system
events:
14.2.1 System Event Logging
The primary systemwide event-logging facility uses the syslog function to log events in ASCII format. The
syslog function uses the
syslogd daemon to collect the messages that are logged by the various kernel,
command, utility, and application programs. The syslogd
daemon logs the messages to a local file or forwards the messages to a remote
system, as specified in the /etc/syslog.conf file.
14.2.2 Binary Event Logging
The binary event-logging facility detects
hardware and software events in the kernel and logs the detailed information
in binary format records. Events that are logged by the binary event-logging
facility are also logged by the syslog function in a less
detailed, but still informative, summary message.Note
uerf(8) for more information about using uerf.
Section 14.3.1.2 discusses the /etc/binlog.conf file.dia(8)
14.3 Configuring Event Logging
When you install your system, the default
system and binary event-logging configuration is used. You can change the
default configuration by modifying the configuration files. You can also modify
the binary event-logging configuration, if necessary.
14.3.1 Editing the Configuration Files
If you do not want to use the default system or binary event-logging
configuration, edit the /etc/syslog.conf or /etc/binlog.conf configuration file to specify how the system should log events.
In the files, you specify the facility, which is the source of a message or
the part of the system that generates a message; the priority, which is the
message's level of severity; and the destination for messages.
14.3.1.1 The syslog.conf File
If
you want the syslogd daemon to use a configuration file
other than the default, you must specify the file name with the syslogd -f config_file
command.
#
# syslogd config file
#
# facilities: kern user mail daemon auth syslog lpr binary
# priorities: emerg alert crit err warning notice info debug
#
# [1] [2] [3]
kern.debug /var/adm/syslog.dated/kern.log
user.debug /var/adm/syslog.dated/user.log
daemon.debug /var/adm/syslog.dated/daemon.log
auth.crit;syslog.debug /var/adm/syslog.dated/syslog.log
mail,lpr.debug /var/adm/syslog.dated/misc.log
msgbuf.err /var/adm/crash.dated/msgbuf.savecore
kern.debug /var/adm/messages
kern.debug /dev/console
*.emerg *
| Facility | Description |
|---|---|
| kern | Messages generated by the kernel. These messages cannot be generated by any user process. |
| user | Messages generated by user processes. This is the default facility. |
| Messages generated by the mail system. | |
| daemon | Messages generated by the system daemons. |
| auth | Messages generated by the authorization system (for example: login, su, and getty). |
| lpr | Messages generated by the line printer spooling system (for example: lpr, lpc, and lpd). |
| local0 | Reserved for local use, along with local1 to local7. |
| mark | Receives a message of priority info every 20 minutes, unless a different interval is specified with the syslogd -m option. |
| msgbuf | Kernel syslog message buffer recovered from a system crash. The savecore command and the syslogd daemon use the msgbuf facility to recover system event messages from a crash. |
| * | Messages generated by all parts of the system. |
You can specify the following severity levels, which are listed in order of highest to lowest severity:
| Severity Level | Description |
|---|---|
| emerg or panic | A panic condition. You can broadcast these messages to all users. |
| alert | A condition that you should immediately correct, such as a corrupted system database. |
| crit | A critical condition, such as a hard device error. |
| err | Error messages. |
| warning or warn | Warning messages. |
| notice | Conditions that are not error conditions, but are handled as special cases. |
| info | Informational messages. |
| debug | Messages containing information that is used to debug a program. |
| none | Disables a specific facility's messages. |
You can specify the following message destinations:
| Destination | Description |
|---|---|
| Full pathname | Appends messages to the specified file. You should direct each facility's messages to separate files (for example: kern.log, mail.log, or lpr.log). |
| Host name preceded by an at sign (@) | Forwards messages to the syslogd daemon on the specified host. |
| List of users separated by commas | Writes messages to the specified users if they are logged in. |
| * | Writes messages to all the users who are logged in. |
You can specify in the /etc/syslog.conf file that the syslogd daemon create daily log
files. To create daily log files, use the following syntax to specify the
pathname of the message destination:
/var/adm/syslog.dated/{file}
The file variable specifies the name of the
log file, for example, mail.log or kern.log.
If you specify a /var/adm/syslog.dated/file pathname destination, each day the syslogd daemon creates a subdirectory under the /var/adm/syslog.dated directory and a log file in the subdirectory by using the following
syntax:
/var/adm/syslog.dated/date / file
The date variable specifies the day, month,
and time that the log file was created.
The file variable specifies the name of the
log file you previously specified in the /etc/syslog.conf
file.
The syslogd daemon automatically creates a new date directory every 24 hours and also when you boot the system.
For example, to create a daily log file of all mail messages of level info or higher, edit the /etc/syslog.conf file
and specify an entry similar to the following:
If you specify the previous command, the syslogd
daemon could create the following daily directory and file:
/var/adm/syslog.dated/11-Jan-12:10/mail.log
The following is an example of a /etc/binlog.conf
file:
Each entry in the /etc/binlog.conf file, except the dumpfile event class entry, contains three fields:
The binlogd daemon ignores blank lines and lines
that begin with a number sign (#). You can specify a number sign (#) as the
first character in a line to include comments in the file or to disable an
entry.
The event class and severity level are separated from the destination
by one or more tabs.
You can specify the following event class codes:
mail.info /var/adm/syslog.dated/mail.log
14.3.1.2 The binlog.conf File
If you want the binlogd daemon to use a configuration file other than the default, specify
the file name with the binlogd -f config_file command.
#
# binlogd configuration file
#
# format of a line: event_code.priority destination
#
# where:
# event_code - see codes in binlog.h and man page, * = all events
# priority - severe, high, low, * = all priorities
# destination - local file pathname or remote system hostname
#
#
*.* /usr/adm/binary.errlog
dumpfile /usr/adm/crash/binlogdumpfile
102.high /usr/adm/disk.errlog
[1] [2] [3]
| Class Code | General |
|---|---|
| * | All event classes. |
| dumpfile | Specifies the recovery of the kernel binary event log buffer from a crash dump. A severity level cannot be specified. |
| Class Code | Hardware-Detected Events |
|---|---|
| 100 | CPU machine checks and exceptions |
| 101 | Memory |
| 102 | Disks |
| 103 | Tapes |
| 104 | Device controller |
| 105 | Adapters |
| 106 | Buses |
| 107 | Stray interrupts |
| 108 | Console events |
| 109 | Stack dumps |
| 199 | SCSI CAM events |
| Class Code | Software-Detected Events |
|---|---|
| 201 | CI port-to-port-driver events |
| 202 | System communications services events |
| Class Code | Informational ASCII Messages |
|---|---|
| 250 | Generic |
| Class Code | Operational Events |
|---|---|
| 300 | Startup ASCII messages |
| 301 | Shutdown ASCII messages |
| 302 | Panic messages |
| 310 | Time stamp |
| 350 | Diagnostic status messages |
| 351 | Repair and maintenance messages |
You can specify the following severity levels:
| Severity Level | Description |
|---|---|
| * | All severity levels |
| severe | Unrecoverable events that are usually fatal to system operation |
| high | Recoverable events or unrecoverable events that are not fatal to system operation |
| low | Informational events |
You can specify the following destinations:
| Destination | Description |
|---|---|
| Full pathname | Specifies the file name to which the binlogd daemon appends the binary event records. |
| @hostname | Specifies the name of the host (preceded by an @) to which the binlogd daemon forwards the binary event records. If you specify dumpfile for an event class, you cannot forward records to a host. |
/dev/MAKEDEV /dev/klog
Also, the binlogd daemon cannot log local system
events unless the /dev/kbinlog character special file exists.
If the /dev/kbinlog file does not exist, create it by
using the following command syntax:
/dev/MAKEDEV /dev/kbinlog
Refer to the
The command that starts the syslogd daemon has the following syntax:
/usr/sbin/syslogd[-d] [-fconfig_file] [-mmark_interval]
Refer to the
The syslogd daemon reads messages from the following:
Messages from other programs use the openlog, syslog, and closelog calls.
When the syslogd daemon is started, it creates the /var/run/syslog.pid file, where the syslogd daemon
stores its process identification number. Use the process identification
number to stop the syslogd daemon before you shut down
the system.
During normal system operation, the syslogd daemon
is called if data is put in the kernel syslog message buffer, located in physical
memory. The syslogd daemon reads the /dev/klog file and gets a copy of the kernel syslog message buffer. The syslogd daemon starts at the beginning of the buffer and sequentially
processes each message that it finds. Each message is prefixed by facility
and priority codes, which are the same as those specified in the /etc/syslog.conf file. The syslogd daemon then
sends the messages to the destinations specified in the file.
To stop
the syslogd event-logging daemon, use the following command:
You can apply changes that you make to the /etc/syslog.conf configuration file without shutting down the system by using the
following command:
The command that starts
the binlogd daemon has the following syntax:
/usr/sbin/binlogd[-d] [-fconfig_file]
Refer to the
The binlogd daemon reads binary event records from
the following:
When the binlogd daemon starts, it creates the /var/run/binlogd.pid file, where the binlogd
daemon stores its process identification number. Use the process identification
number to stop or reconfigure the binlogd daemon.
During normal system operation, the binlogd daemon
is called if data is put into the kernel's binary event-log buffer or if data
is received on the Internet domain socket. The binlogd
daemon then reads the data from the /dev/kbinlog special
file or from the socket. Each record contains an event class code and a severity
level code. The binlogd daemon processes each binary event
record and logs it to the destination specified in the /etc/binlog.conf file.
To stop the binlogd daemon, use the following
command:
You can apply changes that you make to the /etc/binlog.conf configuration file without shutting down the system by using the
following command:
The /sys/data/binlog_data.c file defines the binary event-logger configuration. The default
configuration specifies a buffer size of 24K bytes, enables binary event logging,
and disables the logging of kernel ASCII messages. You can modify the configuration
by changing the values of the binlog_bufsize and binlog_status keywords in the file.
The binlog_bufsize keyword specifies the size of
the kernel buffer that the binary event logger uses. The size of the buffer
can be between 8 kilobytes (8192 bytes) and 48 kilobytes (49152 bytes). Small
system configurations, such as workstations, can use a small buffer. Large
server systems that use many disks may need a large buffer.
The binlog_status keyword specifies the behavior
of the binary event logger. You can specify the following values for the binlog_status keyword:
After you modify the /sys/data/binlog_data.c file,
you must rebuild and boot the new kernel.
The msgbuf.err entry in the /etc/syslog.conf file specifies the destination of the kernel syslog message buffer msgbuf that is recovered from the dump file. The default /etc/syslog.conf file entry for the kernel syslog message buffer
file is as follows:
The dumpfile entry in the /etc/binlog.conf file specifies the file name destination for the kernel binary
event-log buffer that is recovered from the dump file. The default /etc/binlog.conf file entry for the kernel binary event-log buffer
file is as follows:
If a crash occurs, the syslogd
and binlogd daemons cannot read the /dev/klog and /dev/kbinlog special files and process the
messages and binary event records. When you reboot the system, the savecore command runs and, if a dump file exists, recovers the kernel
syslog message and binary event-log buffers from the dump file. After savecore runs, the syslogd and binlogd daemons are started.
The syslogd daemon reads the syslog message buffer
file, checks that its data is valid, and then processes it in the same way
that it normally processes data from the /dev/klog file,
using the information in the /etc/syslog.conf file.
The binlogd daemon reads the binary event-log buffer
file, checks that its data is valid, and then processes the file in the same
way that it processes data from the /dev/kbinlog special
file, using the information in the /etc/binlog.conf file.
After the syslogd and binlogd
daemons are finished with the buffer files, the files are deleted.
You can also use the cron daemon to specify that
log files be deleted. The following is an example of a crontab
file entry:
The previous command line causes all directories under /var/adm/syslog.dated that were modified more than 5 days ago to be deleted, along with
their contents, every day at 1:05. Refer to the
This chapter discusses how Environmental Monitoring is implemented on
AlphaServer systems.
The loadable kernel module does not include platform specific code (such
as the location of status registers). It is transparent to the kernel module
which options are supported by a platform. That is, the kernel module and
platform are designed to return valid data if an option is supported, a fixed
constant for unsupported options, or null.
14.3.2 Creating the Special Files
The syslogd daemon cannot
log kernel messages unless the /dev/klog character special
file exists. If the /dev/klog file does not exist, create
it by using the following command syntax:
MAKEDEV(8) reference page for more information.
14.3.3 Starting and Stopping the Event-Logging Daemons
The syslogd and binlogd
daemons are automatically started by the init program during
system startup. However, you must ensure that the daemons are started. You
can also specify options with the command that starts the daemons. Refer
to the init(8) reference page for more information.
14.3.3.1 The syslogd Daemon
You
must ensure that the syslogd daemon is started by the init program. If the syslogd daemon is not started
or if you want to specify options with the command that starts the syslogd daemon, you must edit the /sbin/init.d/syslog
file and either include or modify the syslogd command line.
Note that you can also invoke the command manually.syslogd(8) reference page for information about command
options.
Note
# kill `cat /var/run/syslog.pid`
# kill -HUP `cat /var/run/syslog.pid`
14.3.3.2 The binlogd Daemon
You
must ensure that the init program starts the binlogd daemon. If the binlogd daemon does not
start, or if you want to specify options with the command that starts the binlogd daemon, you must edit the /sbin/init.d/syslog
file and either include or modify the binlogd command line.
Note that you can also invoke the command manually.binlogd(8) reference page for information on command options.
# kill `cat /var/run/binlogd.pid`
# kill -HUP `cat /var/run/binlogd.pid`
14.3.4 Configuring the Kernel Binary Event Logger
You can configure the kernel binary event logger by modifying the default
keywords and rebuilding the kernel. You can scale the size of the kernel
binary event-log buffer to meet your systems needs. You can enable and disable
the binary event logger and the logging of kernel ASCII messages into the
binary event log.
14.4 Recovering Event Logs After a System Crash
You can recover unprocessed messages and binary event-log
records from a system crash when you reboot the system.
msgbuf.err /var/adm/crash/msgbuf.savecore
dumpfile /usr/adm/crash/binlogdumpfile
14.5 Maintaining Log Files
If you specify full pathnames for the message destinations
in the /etc/syslog.conf and /etc/binlog.conf
files, the log files will grow in size. Also, if you configure the syslogd daemon to create daily directories and log files, eventually
there will be many directories and files, although the files themselves will
be small. Therefore, you must keep track of the size and the number of log
files and daily directories and delete the files and directories if they become
unwieldy.
5 1 * * * find /var/adm/syslog.dated -type d -mtime +5 -exec rm -rf '{}' \;crontab(1) reference page
for more information.
14.6 Environmental Monitoring
On any system, thermal levels can increase
because of poor ventilation,
overheating conditions, or fan failure. Without
detection, an unscheduled shutdown
could ensue causing the system's loss of data or damage to the system itself.
By using Environmental Monitoring, the thermal state of AlphaServer systems
can be detected and users can be alerted in time enough to recover or perform
an orderly shutdown of the system.
14.6.1 Environmental Monitoring Framework
The Environmental Monitoring framework consists of four components:
loadable kernel module and
its associated APIs, Server System MIB subagent daemon, the envmond daemon, and the envconfig utility.
14.6.1.1 Loadable Kernel Module
The loadable kernel module and its associated APIs contain the parameters
needed to
monitor and return status on your system's threshold
levels. The kernel module exports server management attributes as described
in Section 14.6.1.1.1 through the kernel configuration manager
(CFG) interface only. It works across all platforms that support server management,
and provides compatibility for other server management systems under development.
The kernel module is supported on all Alpha systems running Version 4.0A
or higher of the Digital UNIX operating system.
14.6.1.1.1 Specifying Loadable Kernel Attributes
The loadable kernel module exports the parameters listed in Table 14-12
to the kernel configuration manager (CFG).
The get_info() function obtains dynamic environmental
data using the function types described in Table 14-13.
14.6.1.1.2 Obtaining Platform Specific Functions
The loadable kernel module must return environmental status based on
the platform being queried. This section describes the kernel interfaces
used. To obtain environmental status, the
get_info()
function is used. Calls to the get_info() function are
filtered through the platform_callsw[] table.
14.6.1.1.3 Server System MIB Subagent
The Server System MIB Agent, (which is an eSNMP sub-agent) is used to
export a subset of the Environmental Monitoring parameters specified in the
Server System MIB. The Digital Server System MIB exports a common set of
hardware specific
parameters across all server platforms on all operating
systems offered by Digital. Table 14-14 maps the subset
of Server System MIB variables that support
Environmental Monitoring
to the kernel parameters described in Section 14.6.1.1.1.
For each Server System MIB variable listed in Table 14-14, code is provided in the subagent daemon, which accesses the appropriate parameter from the kernel module through the CFG interface.
To enable Environmental Monitoring, the envmond
daemon must be started during the
system boot, but after the eSNMP and Server System MIB agents have been started.
You can customize the envmond daemon using the
envconfig utility.
14.6.1.2 Monitoring Environmental Thresholds
To monitor the system environment, the envmond daemon
is used. You can customize the daemon by using the envconfig
utility. The following sections discuss the daemon and utility. For more
information, see the envmond and envconfig
reference pages.
14.6.1.2.1 Environmental Monitoring Daemon
By using the Environmental Monitoring daemon, envmond,
threshold levels can be checked and corrective action can ensue before damage
occurs to your system. Then envmond daemon performs the
following:
To query the system, the envmond daemon
uses the base operating system command /usr/sbin/snmp_request
to obtain the current values
of the environment variables specified in the Server System MIB.
14.6.1.2.2 Customizing the envmond Daemon
You can use the envconfig utility to customize how
the environment is queried by the envmond daemon. These
customizations are stored in the
/etc/rc.config file, which is read by the envmond
daemon during startup. Use the envconfig utility to perform
the following: