![[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:
# diskx -h
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.
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 intro(2) and sigvec(2) reference pages.
fsx(8) reference page.
Do not test NFS file systems with the fsx command. Note
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:
# fsx -p5 -f/usr -t60 &
The files that you need to run the memx exerciser include the following:
memx(8) reference pageThe 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:
# memx -m4095 -p5 -t60 &
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:
# shmx &
The following example runs three memory segments of 100,000 bytes for 180 minutes:
# shmx -t180 -m100000 -s3 &
Some of the tests involve writing to the disk; for this reason, use the exerciser cautiously on disks that contain useful data that the exerciser could overwrite. Tests that write to the disk first check for the existence of file systems on the test partitions and partitions that overlap the test partitions. If a file system is found on these partitions, you are prompted to determine if testing should continue. Caution
diskx(8) reference page.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:
disktab(4) reference page for more information.
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:
-perf_min 512
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:
# diskx -f /dev/rrz0 -r
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:
# diskx -f /dev/rz0a -o diskx.out -d -debug 10
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:
# diskx -f /dev/rz0a -o diskx.out -p -S
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:
# diskx -f /dev/rrz0 -r &; diskx -f /dev/rrz1 -r &; diskx -f /dev/rrz2 -r &
tapex(8) reference page.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:
-min_rs 512
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:
| tapex Flag | Flag and Parameter Descriptions |
|---|---|
| -a | Specifies the performance measurement
test, which calculates the tape transfer bandwidth for writes and reads to
the tape by timing data transfers. The following parameters can be used with
the -a flag:
|
| -b | Causes the write/read tests to run continuously until the process is killed. This flag can be used with the -r and -g flags. |
| -c | Enables caching on the device, if supported. This flag does not specifically test caching; it enables the use of caching on a tape device while other tests are running. |
| -C | Disables caching on TMSCP tape devices. If the tape device is a TMSCP unit, then caching is the default mode of test operation. This flag causes the tests to run in noncaching mode. |
| -d | Tests the ability to append records
to the media. First, the test writes records to the tape. Then, it repositions
itself back one record and appends additional records. Finally, the test does
a read verification. This test simulates the behavior of the tar -r command. The following parameters can be used with the -d flag:
|
| -e | Specifies EOM test. First, this test writes data to fill a tape; this action can take some time for long tapes. It then performs reads and writes past the EOM; these actions should fail. Finally, it enables writing past the EOM, writes to the tape, and reads back the records for validation purposes. |
| The following parameters can be used
with the -e flag:
| |
| -E | Runs an extensive series of tests in sequential order. Depending on tape type and CPU type, this series of tests can take up to 10 hours to complete. |
| -f /dev/rmtl#? | Specifies the name of the device special file that corresponds to the tape unit being tested. The number sign variable (#) specifies the unit number. The question mark variable (?) specifies the letter h for the high density device or l for the low density device. The default tape device is /dev/rmt0h. |
| -F | Specifies the file-positioning tests.
First, files are written to the tape and verified. Next, every other file
on the tape is read. Then, the previously unread files are read by traversing
the tape backwards. Finally, random numbers are generated, the tape is positioned
to those locations, and the data is verified. Each file uses a different record
size. The following parameters can be used with the -F
flag:
|
| -G | Specifies the file-positioning tests on a tape containing data. This flag can be used with the -F flag to run the file position tests on a tape that has been written to by a previous invocation of the -F test. To perform this test, you must use the same test parameters (for example, record size and number of files) that you used when you invoked the -F test to write to the tape. No other data should have been written to the tape since the previous -F test. |
| -g | Specifies random record size tests.
This test writes records of random sizes. It reads in the tape, specifying
a large read size; however, only the amount of data in the randomly sized
record should be returned. This test only checks return values; it does not
validate record contents. The following parameter is used with the -g flag:
|
| -h | Displays a help message describing the tape exerciser. |
| -i | Specifies interactive mode. In this
mode, you are prompted for various test parameters. Typical parameters include
the record size and the number of records to write. The following scaling
factors are allowed:
|
| -j | Specifies the write phase of the tape-transportability
tests. This test writes a number of files to the tape and then verifies the
tape. After the tape has been successfully verified, it is brought off line,
moved to another tape unit, and read in with the -k
flag. This test proves that you can write to a tape on one drive and read
from a tape on another drive. The -j flag is used
with the -k flag. Note the -j
flag and the -k flag must use the same parameters.
The following parameters can be used with the -j
and -k flags:
|
| -k | Specifies the read phase of the tape-transportability tests. This test reads a tape that was written by the -j test and verifies that the expected data is read from the tape. This test proves that you can write to a tape on one drive and read from a tape on another drive. As stated in the description of the -j flag, any parameters specified with the -j flag must be specified with the -k flag. (See the description of the -j flag for information on the parameters that apply to the -j and -k flags.) |
| -L | Specifies the media loader test. For sequential stack loaders, the media is loaded, written to, and verified. Then, the media is unloaded, and the test is run on the next piece of media. This verifies that all of the media in the input deck can be written to. To run this test in read-only mode, also specify the -w flag. |
| -l | Specifies the EOF test. This test verifies that a zero byte count is returned when a tape mark is read and that an additional read fetches the first record of the next tape file. |
| -m | Displays tape contents. This is not a test. This flag reads the tape sequentially and prints out the number of files on the tape, the number of records in each file, and the size of the records within the file. The contents of the tape records are not examined. |
| -o filename | Sends output to the specified file name. The default sends output to the terminal screen. |
| -p | Runs both the record-positioning and file-positioning tests. For more information, refer to descriptions of the -R and -F flags. |
| -q | Specifies the command timeout test. This test verifies that the driver allows enough time for completion of long operations. This test writes files to fill the tape. It then performs a rewind, followed by a forward skip to the last file. This test is successful if the forward skip operation is completed without error. |
| -r | Specifies the record size test. A number
of records are written to the tape and then verified. This process is repeated
over a range of record sizes. The following parameters can be used with the -r flag:
|
| -R | Specifies the record-positioning test.
First, records are written to the tape and verified. Next, every other record
on the tape is read. Then, the other records are read by traversing the tape
backwards. Finally, random numbers are generated; the tape is positioned
to those locations, and the data is verified. The following parameters can
be used with the -R flag:
|
| -s | Specifies the record size behavior
test. Verifies that a record that is read returns one record (at most) or
the read size, whichever is less. The following parameters can be used with
the -s flag:
|
| -S | Specifies single record size test.
This test modifies the record size test (the -r flag)
to use a single record size. The following parameters can be used with the -S flag:
|
| |
| -T | Displays output to the terminal screen. This flag is useful if you want to log output to a file with the -o flag and also have the output displayed on your terminal screen. This flag must be specified after the -o flag in the command line. |
| -v | Specifies verbose mode. This flag causes detailed information to be output. For example, it lists the operations the exerciser is performing (such as record counts), and detailed error information. Information provided by this flag can be useful for debugging purposes. |
| -V | Specifies enhanced verbose mode. This flag causes output of more detailed information than the -v flag. The additional output consists of status information on exerciser operations. Information provided by this flag can be useful for debugging purposes. |
| -w | Opens the tape as read-only. This mode is useful only for tests that do not write to the media. For example, it allows the -m test to be run on a write-protected media. |
| -Z | Initializes the read buffer to the nonzero value 0130. This can be useful for debugging purposes. If the -Z flag is not specified, all elements of the read buffer are initialized to zero. Many of the tests first initialize their read buffer and then perform the read operation. After reading a record from the tape, some tests validate that the unused portions of the read buffer remain at the value to which they were initialized. For debugging purposes, you can set this initialized value to a number other than zero. In this case, you can use the arbitrary value 0130. |
# tapex -f /dev/rmt1h -E -o tapex.out
# tapex -g -v
# tapex -r -min_rs 10k -max_rs 20k
# 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 cmx(8)
reference page.
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:
# cmx -l 22 34 -t45 &
The following example exercises lines tty00 through tty07 until you press Ctrl/C:
# cmx -l 00-07
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 uerf facility remains as a component of Digital UNIX, but will be retired in a future release of the operating system. See Appendix D or Note
uerf(8) for more information about using uerf.
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:
dia(8)
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:
# # 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 *
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 the following facilities:
| 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. |
| 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:
The file variable specifies the name of the log file, for example, mail.log or kern.log.
/var/adm/syslog.dated/date / file
The date variable specifies the day, month, and time that the log file was created.
mail.info /var/adm/syslog.dated/mail.log
/var/adm/syslog.dated/11-Jan-12:10/mail.log
The following is an example of a /etc/binlog.conf file:
# # 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]
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:
| 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 MAKEDEV(8) reference page for more information.
init(8) reference page for more information.
The command that starts the syslogd daemon has the following syntax:
/usr/sbin/syslogd[-d] [-fconfig_file] [-mmark_interval]
Refer to the syslogd(8) reference page for information about command
options.
You must ensure that the /var/adm directory is mounted, or the syslogd daemon will not work correctly. Note
The syslogd daemon reads messages from the following:
Messages from other programs use the openlog, syslog, and closelog calls.
To stop the syslogd event-logging daemon, use the following command:
# kill `cat /var/run/syslog.pid`
# kill -HUP `cat /var/run/syslog.pid`
The command that starts the binlogd daemon has the following syntax:
/usr/sbin/binlogd[-d] [-fconfig_file]
Refer to the binlogd(8) reference page for information on command options.
The binlogd daemon reads binary event records from the following:
To stop the binlogd daemon, use the following command:
# kill `cat /var/run/binlogd.pid`
# kill -HUP `cat /var/run/binlogd.pid`
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.
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:
msgbuf.err /var/adm/crash/msgbuf.savecore
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:
dumpfile /usr/adm/crash/binlogdumpfile
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.
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:
5 1 * * * find /var/adm/syslog.dated -type d -mtime +5 -exec rm -rf '{}' \;
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 crontab(1) reference page
for more information.
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.
| Parameter | Purpose |
|---|---|
| env_current_temp | Specifies the current temperature of the system. If a system is configured with the KCRCM module, the temperature returned is in Celsius. If a system does not support temperature readings and a temperature threshold has not been exceeded, a value of -1 is returned. If a system does not support temperature readings and a temperature threshold is exceeded, a value of -2 is returned. |
| env_high_temp_thresh | Provides a system specific operating temperature threshold. The value returned is a hardcoded, platform specific temperature in Celsius. |
| env_fan_status | Specifies a noncritical fan status. The value returned is a bit value of zero (0). This value will differ when the hardware support is provided for this feature. |
| env_ps_status | Provides the status of the redundant power supply. On platforms that provide interrupts for redundant power supply failures, the corresponding error status bits are read to determine the return value. A value of 1 is returned on error; otherwise, a value of zero (0) is returned. |
| env_supported | Indicates whether or not the platform supports server management and environmental monitoring. |
The get_info() function obtains dynamic environmental data using the function types described in Table 14-13.
| Function Type | Use of Function |
|---|---|
| GET_SYS_TEMP | Reads the system's internal temperature on platforms that have a KCRCM module configured. |
| GET_FAN_STATUS | Reads fan status from error registers. |
| GET_PS_STATUS | Reads redundant power supply status from error registers. |
| Server System MIB Variable Name | Kernel Module Parameter |
|---|---|
| svrThSensorReading | env_current_temp |
| svrThSensorStatus | env_current_temp |
| svrThSensorHighThresh | env_high_temp_thresh |
| svrPowerSupplyStatus | env_ps_temp |
| svrFanStatus | env_fan_status |
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.