This chapter provides important information that you need in order to
work with the Tru64 UNIX 5.1A and TruCluster 5.1A Patch Kit-0003.
1.1 Patch Process Resources
We provide Web sites to help you with the patching process:
To obtain the lasest patch kit for your operating system and cluster:
To view or print the lastest version of the Patch Kit Installation Instructions or the Patch Summary and Release Notes for a specific patch kit:
To visit our main support page:
To visit the Tru64 UNIX homepage:
The following storage space is required to successfully install this
patch kit:
Base Operating System
Temporary Storage Space
A total of ~250 MB of storage space is required to untar this patch
kit.
We recommend that this kit not be placed in the
/,
/usr, or
/var
file systems because doing so may
unduly constrain the available storage space for the patching activity.
Permanent Storage Space
Up to ~71 MB of storage space in
/var/adm/patch/backup
may be required for archived original files if you choose to install and
revert all patches.
See the
Patch Kit Installation Instructions
for more information.
Up to 73 MB of storage space in
/var/adm/patch
may
be required for original files if you choose to install and revert all patches.
See the
Patch Kit Installation Instructions
for more
information.
Up to ~1346 KB of storage space is required in
/var/adm/patch/doc
for patch abstract and README documentation.
A total of ~176 KB of storage space is needed in
/usr/sbin/dupatch
for the patch management utility.
TruCluster Server
Temporary Storage Space
A total of ~250 MB of storage space is required to untar this patch
kit.
We recommend that this kit not be placed in the
/,
/usr, or
/var
file systems because doing so may
unduly constrain the available storage space for the patching activity.
Permanent Storage Space
Up to ~24 MB of storage space in
/var/adm/patch/backup
may be required for archived original files if you choose to install and
revert all patches.
See the
Patch Kit Installation Instructions
for more information.
Up to ~25 MB of storage space in
/var/adm/patch
may
be required for original files if you choose to install and revert all patches.
See the
Patch Kit Installation Instructions
for more
information.
Up to ~1221 KB of storage space is required in
/var/adm/patch/doc
for patch abstract and README documentation.
A total of ~184 KB of storage space is needed in
/usr/sbin/dupatch
for the patch management utility.
1.3 Inclusion of Base Level in tar File Name
With this release, the name of the
tar
file containing
the patch distribution has been expanded to include the baselevel for which
this kit was built.
This formerly internal baselevel number has become a common
way of identifying kits.
For complete information, see Section 1.3 of the
Patch Kit Installation Instructions.
1.4 Problem with lockmode=4 on AlphaServers with QLogic SCSI Disk Controllers
When an AlphaServer GS Series system with a QLogic SCSI disk controller
is set to lockmode=4, the system may panic on boot.
We will provide a fix
for this in the near future.
1.5 Updates for Rolling Upgrade Procedures
The following sections provide information on rolling upgrade procedures.
1.5.1 Unrecoverable Failure Procedure
The procedure to follow if you encounter unrecoverable failures while
running
dupatch
during a rolling upgrade has changed.
The
new procedure calls for you to run the
clu_upgrade -undo install
command and then set the system baseline.
The procedure is explained
in the
Patch Kit Installation Instructions
as notes in
Section 5.3 and Section 5.6.
1.5.2 During Rolling Upgrade, Do Not Add or Delete OSF, TCR, or IOSWW Subsets
During a rolling upgrade, do not use the
/usr/sbin/setld
command to add or delete any of the following subsets:
Base Operating System subsets (those with the prefix
OSF).
TruCluster Server subsets (those with the prefix
TCR).
Worldwide Language Support (WLS) subsets (those with the prefix
IOSWW).
Adding or deleting these subsets during a roll creates inconsistencies
in the tagged files.
1.5.3 depord Warnings and cat Errors
This release note explains
depord
warnings and
cat
errors displayed during a rolling upgrade with patches.
These warnings are only encountered if a rolling upgrade has been performed
on the lead member, followed by the installation of patches on the lead member.
When the remaining members perform the roll operation using the
clu_upgrade
roll command, a number of warning and error messages
are displayed.
The warning messages are from the
depord
command and state that the
.ctrl
file for patch subsets
cannot be found.
These
depord
warnings are followed by error messages
from the
cat
command stating that the
.inv
file for patch subsets cannot be opened.
These warning and error messages
are benign and can be ignored.
The following is a sample of the warning and
error messages that will be displayed:
depord: warning, no .ctrl file for "TCRPAT00008600520"
depord: warning, no .ctrl file for "TCRPAT00008400520"
depord: warning, no .ctrl file for "TCRPAT00008200520"
depord: warning, no .ctrl file for "TCRPAT00008000520"
... additional messages skipped ...
cat: cannot open
/var/cluster/members/{memb}/adm/update/tmpstaydir/instctrl/OSFPAT00000032520.inv
cat: cannot open
/var/cluster/members/{memb}/adm/update/tmpstaydir/instctrl/OSFPAT00000500520.inv
... additional messages skipped ...
When you undo the stages of a rolling upgrade, the stages must be undone
in the correct order.
However, the
clu_upgrade
command
incorrectly allows a user undoing the stages of a rolling patch to run the
clu_upgrade undo preinstall
command before running the
clu_upgrade undo install
command.
The problem is that in the install stage,
clu_upgrade
cannot tell from the
dupatch
flag files whether the roll
is going forward or backward.
This ambiguity allows a user who is undoing
a rolling patch to run the
clu_upgrade undo preinstall
command without first having run the
clu_upgrade undo install
command.
To avoid this problem when undoing the stages of a rolling patch, make
sure to follow the documented procedure and undo the stages in order.
1.5.5 Ignore Message About Missing ladebug.cat File During Rolling Upgrade
When installing the patch kit during a rolling upgrade, you may see the following error and warning messages. You can ignore these messages and continue with the rolling upgrade.
Creating tagged files.
...............................................................................
.....
*** Error ***
The tar commands used to create tagged files in the '/usr' file system have
reported the following errors and warnings:
tar: lib/nls/msg/en_US.88591/ladebug.cat : No such file or directory
.........................................................
*** Warning ***
The above errors were detected during the cluster upgrade. If you believe that
the errors are not critical to system operation, you can choose to continue.
If you are unsure, you should check the cluster upgrade log and refer
to clu_upgrade(8) before continuing with the upgrade.
1.5.6 clu_upgrade undo of Install Stage Can Result in Incorrect File Permissions
This note applies only when both of the following are true:
You are using
installupdate,
dupatch, or
nhd_install
to perform a rolling
upgrade.
You need to undo the
install
stage; that
is, to use the
clu_upgrade undo install
command.
In this situation, incorrect file permissions can be set for files on
the lead member.
This can result in the failure of
rsh,
rlogin, and other commands that assume user IDs or identities by
means of
setuid.
The
clu_upgrade undo install
command must be run
from a nonlead member that has access to the lead member's boot disk.
After
the command completes, follow these steps:
Boot the lead member to single-user mode.
Run the following script:
#!/usr/bin/ksh -p
#
# Script for restoring installed permissions
#
cd /
for i in /usr/.smdb./$(OSF|TCR|IOS|OSH)*.sts
do
grep -q "_INSTALLED" $i 2>/dev/null && /usr/lbin/fverify -y <"${i%.sts}.inv"
done
Rerun
installupdate,
dupatch,
or
nhd_install, whichever is appropriate, and complete
the rolling upgrade.
For information about rolling upgrades, see Chapter 7 of the
Cluster Installation
manual,
installupdate(8)clu_upgrade(8)1.5.7 Missing Entry Messages Can Be Ignored During Rolling Patch
During the
setup
stage of a rolling patch, you might
see a message like the following:
Creating tagged files. ............................................................................ ............................................................................ ............................................ clubase: Entry not found in /cluster/admin/tmp/stanza.stdin.597530 clubase: Entry not found in /cluster/admin/tmp/stanza.stdin.597568
An
Entry not found
message will appear once for each
member in the cluster.
The number in the message corresponds to a PID.
You can safely ignore this
Entry not found
message.
1.5.8 Relocating AutoFS During a Rolling Upgrade on a Cluster
This note applies only to performing rolling upgrades on cluster systems that use AutoFS.
During a cluster rolling upgrade, each cluster member is singly halted and rebooted several times. The Patch Kit Installation Instructions direct you to manually relocate applications under the control of Cluster Application Availability (CAA) prior to halting a member on which CAA applications run.
Depending on the amount of NFS traffic, the manual relocation of AutoFS may sometimes fail. Failure is most likely to occur when NFS traffic is heavy. The following procedure avoids that problem.
At the start of the rolling upgrade procedure, use the
caa_stat
command to learn which member is running AutoFS.
For example:
# caa_stat -t Name Type Target State Host ------------------------------------------------------------ autofs application ONLINE ONLINE rye cluster_lockd application ONLINE ONLINE rye clustercron application ONLINE ONLINE swiss dhcp application ONLINE ONLINE swiss named application ONLINE ONLINE rye
To minimize your effort in the procedure described as follows, it is desirable to perform the roll stage last on the member where AutoFS runs.
When it comes time to perform a manual relocation on a member where AutoFS is running, follow these steps:
Stop AutoFS by entering the following command on the member where AutoFS runs:
# /usr/sbin/caa_stop -f autofs
Perform the manual relocation of other applications running on that member:
# /usr/sbin/caa_relocate -s current_member -c target_member
After the member that had been running AutoFS has been halted as part of the rolling upgrade procedure, restart AutoFS on a member that is still up. (If this is the roll stage and the halted member is not the last member to be rolled, you can minimize your effort by restarting AutoFS on the member you plan to roll last.)
On a member that is up, enter the following command to restart AutoFS. (The member where AutoFS is to run, target_member, must be up and running in multi-user mode.)
# /usr/sbin/caa_startautofs -c target_member
Continue with the rolling upgrade procedure.
This section describes updates to the
sys_check
command.
1.6.1 TMPDIR Variable
If the TMPDIR environment variable is not defined, then
sys_check
-escalate
will always put the escalate.tar files in
/var/tmp
even if you specify an alternate directory.
To work around this
problem, you must first set and export the TMPDIR environment variable to
the directory where you want
sys_check
to put the
escalate.tar
files.
For example, if you want
sys_check
to put the escalate.tar files in
/var/adm,
then you must execute the following commands before running
sys_check
-escalate.
# ksh # export TMPDIR=/var/adm # sys_check -escalate
1.6.2 sys_check Version 125 Web Kit
The following information is for users who have installed
sys_check
Version 125 web kit or higher and are currently using
that version of
sys_check
in the web kit as the system
default version.
This patch kit contains
sys_check
Version 124.
If
you have already installed the
sys_check
Version 125 web
kit or higher, then installing this patch kit will downgrade the version of
sys_check
that is being used by the system.
However, you can easily
set the system default back to the version of
sys_check
that you downloaded from the web by using the
/usr/sbin/use_sys_check
script.
For example, type
use_sys_check 125
at the command line prompt to set
sys_check
Version 125
as the system default.
If you wish to delete the
sys_check
patch (that is,
sys_check
Version 124) then you should make sure that Version 124
is the system default version before deleting the patch.
You can verify this
by examining the output of the
sys_check -v
command.
If
124.0 is not the default version, then you should run the
/usr/sbin/use_sys_check
124
command to set the system default version of
sys_check
to version 124.
Setting the system default to 124 ensures that
the Version 124
sys_check
files get removed when the patch
is deleted.
After you delete the patch, the system default version of
sys_check
will automatically be set to the version of
sys_check
that you downloaded from the web.
This is because
dupatch
saves the symbolic links that point to the web kit location
when the patch gets installed and will restore these symbolic links when the
patch gets deleted.
If you delete the patch and the system default version is not set to
124, then Version 124 will remain on the system because
sys_check
Version 124 has been backed up by the web kit (for example,
/usr/sbin/sys_check.124.0).
You will encounter problems if you delete the
sys_check
web kit and then delete this patch kit.
This is because
dupatch
will restore the symbolic links to the web kit location when the
patch is deleted.
If you have deleted the web kit, then the symbolic links
will point to non-existent files.
You can fix this problem by re-installing
the
sys_check
web kit.
1.7 When Taking a Cluster Member to Single-User Mode, First Halt the Member
To take a cluster member from multi-user mode to single-user mode, first halt the member and then boot it to single-user mode. For example:
# shutdown -h now >>> boot -fl s
Halting and booting the system ensures that it provides the minimal set of services to the cluster and that the running cluster has a minimal reliance on the member running in single-user mode.
When the system reaches single-user mode, run the following commands:
# init s # bcheckrc # lmf reset
1.8 Additional Steps Required When Installing Patches Before Cluster Creation
This note applies only if you install a patch kit before creating a cluster; that is, if you do the following:
Install the Tru64 UNIX base kit.
Install the TruCluster Server kit.
Install the Version 5.1A Patch Kit-0003 before running the
clu_create
command.
In this situation, you must then perform three additional steps:
Run
versw, the version switch command,
to set the new version identifier:
# /usr/sbin/versw -setnew
Run
versw
to switch to the new version:
# /usr/sbin/versw -switch
Run the
clu_create
command to create your
cluster:
# /usr/sbin/clu_create
1.9 Problems with clu_upgrade switch Stage
If the
clu_upgrade switch
stage does not complete
successfully, you may see a message like the following:
versw: No switch due to inconsistent versions
The
problem can be due to one or more members running
genvmunix,
a generic kernel.
Use the command
clu_get_info -full
and note each
member's version number, as reported in the line beginning
Member base O/S version
If a member has a version
number different from that of the other members, shut down the member and
reboot it from
vmunix, the custom kernel.
If multiple
members have the different version numbers, reboot them one at a time from
vmunix.
1.10 Support for SDLT160 Tape Device
You must add the following entries in the
/etc/ddr.dbase
and then run
/sbin/ddr_config
for the new SDLT160 tape
device to be recognized.
Add the following to
/etc/ddr.dbase:
scsi_density_table_size = 0x4a
scsi_tape_density[0x42] = "density_code_42" 0 0
scsi_tape_density[0x43] = "density_code_43" 0 0
scsi_tape_density[0x44] = "density_code_44" 0 0
scsi_tape_density[0x45] = "density_code_45" 0 0
scsi_tape_density[0x46] = "density_code_46" 0 0
scsi_tape_density[0x47] = "density_code_47" 0 0
scsi_tape_density[0x48] = "131000_bpi" 131000 0
scsi_tape_density[0x49] = "190000_bpi" 190000 0
SCSIDEVICE
#
# Matches SDLT320
#
Type = tape
Name = "COMPAQ" "SDLT320"
#
#
PARAMETERS:
TypeSubClass = tk
TagQueueDepth = 0
MaxTransferSize = 0x0fffffb # (16MB - 4)
ReadyTimeSeconds = 120 # seconds
DENSITY:
#
DensityNumber = 0
DensityCode = 0x48
CompressionCode = 0x1
Buffered = 0x1
DENSITY:
#
DensityNumber = 1,5
DensityCode = default
CompressionCode = 0x1
Buffered = 0x1
DENSITY:
#
DensityNumber = 2,4,6,7
DensityCode = default
CompressionCode = 0x0
Buffered = 0x1
DENSITY:
#
DensityNumber = 3
DensityCode = 0x48
CompressionCode = 0x0
Buffered = 0x1
Run
/sbin/ddr_config
(see
ddr_config(8) for more information).
1.11 Release Note for Tru64 UNIX Patch 156.00
This release note updates the
envconfig(8) reference
page.
envconfig(8)
NAME
envconfig - Configures the Environmental Monitoring daemon
SYNOPSIS
/usr/sbin/envconfig -c var=value
/usr/sbin/envconfig start | stop
/usr/sbin/envconfig -q
OPTIONS
Environmental Monitoring provides a means of detecting system threshold
conditions, that if exceeded, could result in a loss of data or damage to
the system itself. To detect and notify users of critical conditions, the
envmond daemon is used. This utility, envconfig, is used to customize the
envmond daemon. This section describes the envconfig options you can use
to configure the daemon.
-c var=value
Sets the variables that specify how the system environment is
monitored. These variables are stored in the /etc/rc.config file and are
read by the envmond daemon at system startup. If a variable is not
set, the default value of that variable is assumed.
ENVMON_CONFIGURED
Specifies the state of Environmental Monitoring. If this variable
is set to zero (0), the Environmental Monitoring package is not
started during the system boot. If this variable is set to 1, and
Environmental Monitoring is supported by that platform, it is
started during the system boot. The default value is zero (0).
ENVMON_GRACE_PERIOD
Specifies the time (in minutes) that can elapse between the detec-
tion of a high temperature condition and the shutdown of the sys-
tem. The default value is 15 minutes.
ENVMON_HIGH_THRESH
Specifies the threshold level that can be encountered before the
envmond daemon broadcasts a warning and suggested action.
ENVMON_MONITOR_PERIOD
Specifies the frequency (in seconds) between queries of the system
by the envmond daemon. The default value is 60 seconds.
ENVMON_USER_SCRIPT
Specifies the path of a user-defined script that you want the
envmond daemon to execute when a high threshold level is encoun-
tered. The envmond daemon continues to check the environment after
the script has executed and proceeds as needed should the high
threshold levels persist.
If you set this variable, the envmond daemon directs output from
the script to /dev/console. Output is not displayed on standard
output or written to a file as this is not the behavior of the dae-
mon. To display on standard output, explicitly specify the logger
command within the user defined script
ENVMON_SHUTDOWN_SCRIPT
Specifies the path of a user-defined shutdown script that you want
the envmond daemon to execute when a shutdown condition is encoun-
tered. The envmond daemon will execute this script in place of
/sbin/shutdown. If you want the system to be shut down and you
configure a script for ENVMON_SHUTDOWN_SCRIPT you must execute
/sbin/shutdown from within your script. If you do not specify
anything for ENVMON_SHUTDOWN_SCRIPT envmond will, by default,
run /sbin/shutdown when a shutdown condition is encountered.
If you set this variable, the envmond daemon directs output from
the script to /dev/console. Output is not displayed on standard
output or written to a file as this is not the behavior of the dae-
mon. To display on standard output, explicitly specify the logger
command within the user-defined script.
start | stop
Turns the envmond daemon on or off after system startup.
-q Displays the values of ENVMON_CONFIGURED, ENVMON_GRACE_PERIOD,
ENVMON_HIGH_THRESH, ENVMON_MONITOR_PERIOD, ENVMON_USER_SCRIPT,
and ENVMON_SHUTDOWN_SCRIPT as specified in the /etc/rc.config
file. If a specified entry is not found, the environmental
variable is not displayed.
DESCRIPTION
The envconfig utility is used to customize the envmond daemon. You must
have root privileges to use this utility. Using this utility, you can:
+ Specify whether or not Environmental Monitoring is turned on or off at
system startup.
+ Specify how much time can elapse between the envmond daemon encounter-
ing a critical condition and the daemon initiating an orderly shutdown
of the system.
+ Specify how frequently the envmond daemon queries the system for
information.
+ Start and stop the envmond after Environmental Monitoring has been
turned on at system startup.
+ Display the settings of the environment variables as specified in the
/etc/rc.config file.
Note that the feature that you want to monitor must be supported on a given
platform. For example, the AlphaServer 8400/GS140 supports reporting of
power supply and fan status, the current system temperature, and the max-
imum allowed system temperature.
EXAMPLES
The following procedure describes how you test for and start the environ-
mental monitoring subsystem
1. In multiuser mode, check the status of the environmental monitoring
subsystem as follows:
# /sbin/sysconfig -q envmon
envmon:
env_current_temp = 35
env_high_temp_thresh = 40
env_fan_status = 0
env_ps_status = 0
env_supported = 1
2. If the value of env_supported is 0, configure the envmond daemon and
reboot the system using either of the following methods:
+ At the command prompt, enter the following command:
# /usr/sbin/envconfig -c ENVMON_CONFIGURED=1
+ Use the rcmgr command as follows:
# rcmgr set ENVMON_CONFIGURED 1
This command will enable the envmond daemon and export the variable, creat-
ing the following two lines in the /etc/rc.configfile:
ENVMON_CONFIGURED="1"
export ENVMON_CONFIGURED
You can use the /sbin/sysconfig command to view the system environment at
any time. The envmond daemon will the print warning messages in the event
of a power supply failure, abnormality, or high temperatures. Error logs
are logged in the /var/adm/binary.errlog.
In the following example, the system shuts down in 10 minutes if the tem-
perature does not fall below the critical threshold.
/usr/sbin/envconfig -c ENVMON_GRACE_PERIOD=10
FILES
/etc/rc.config*
Databases that contains the values of the environment monitoring vari-
ables. Note that you must use the rcmgr comand to update the rc.config*
files, particularly on clustered systems.
SEE ALSO
Commands: envmond(8)
1.12 Release Note for Tru64 UNIX Patches 226.00 and 228.00
Patches 226.00 and 228.00 deliver version V2.0-094d of the
libots3
library.
If your system has the Compaq FORTRAN Compiler,
the Developer's Tool Kit (DTK) (OTABASE subset), or a patch that installs
a newer version of this library, do not apply this patch.
If a new revision
of the
libots3
library is already installed on your system,
and you install this patch, you will receive the following informational
message:
Problem installing:
- Tru64_UNIX_V5.1A / Threads Patches
Patch 00xxx.00 - Shared libots3 library fix
./usr/shlib/libots3.so:
is installed by:
OTABASE212
and cannot be replaced by this patch.
This patch will not be installed.
To determine what version of the
libots3
library
is installed on your system, enter the following command:
#
what /usr/shlib/libots3.so libots3.so:
libots3.a V2.0-094 GEM 27 Feb 2001
1.13 Release Note for Tru64 UNIX Patch 252.00
The Essential Services Monitor (ESM) daemon,
esmd,
improves the availability of essential system daemons by automatically restarting
them if they terminate.
The daemon monitors the Event Manager daemon,
evmd, and, in a cluster environment, the CAA daemon,
caad.
Restart activity is reported in the
syslog
daemon.log file.
1.14 Release Note for Tru64 UNIX Patch 807.00
This release note updates the
sys_check(8) reference
page.
syscheck (8)NAME
sys_check, runsyscheck - Generates system configuration information and
analysis
SYNOPSIS
/usr/sbin/sys_check [options...]
OPTIONS
-all
Lists all subsystems, including security information and setld inven-
tory verification. This option may take a long time to complete.
-debug
Outputs debugging information to stderr (standard error output).
-escalate [ xx ]
Creates escalation files for reporting problems to your technical sup-
port representative. This option produces one file,
TMPDIR/escalate.tar unless there are crash dump files; if so,
it also creates two other files: TMPDIR/escalate_vmunix.xx.gz
and TMPDIR/escalate_vmcore.xx.gz. If you use the -escalate
option, sys_check runs with the -noquick option and collects the output
in the escalate.tar file. Optionally, you can specify a number (xx)
with the -escalate option to define a crash number.
See also the ENVIRONMENT VARIABLES section for information on how you
can set the value of TMPDIR.
-evm
Generates Event Manager (EVM) warnings. When EVM is configured, warn-
ings are posted as EVM events identified by the string
sys.unix.sys_check.warning. Six levels of priority ranging from 0-500
are used, as follows:
+ 0 - Information only.
+ 100 - Note
+ 200 - Tuning Note
+ 300 - Tuning Suggestion
+ 400 - Operational
+ 500 - Warning
-frame
Produces frame HTML output, which consists of three files:
sys_checkfr.html, sys_checktoc.html, and sys_check.html (unless you
specify a different file name with the -name option). This option
cannot be used with the -nohtml option. The following options are
available for use with the -frame option:
-name name
Specifies the name to use for the frame files output. The default
name is sys_check.
-dir name
Sets the directory for the frames output. Used only with the
-frame option. The default is the current directory (.).
-help or (-h)
Outputs help information.
-nohtml
Produces text output, consisting of one text file, instead of the
default HTML output. This option cannot be used with the -frame option.
-noquick
Outputs configuration data and the setld scan. Excludes security
information.
-perf
Outputs only performance data and excludes configuration data. This
option takes less time to run than others.
-v Displays the sys_check version number.
-warn
Executes only the warning pass. This option takes less time to run than
other options.
-nowarn
Executes only the data gathering pass.
DESCRIPTION
The sys_check utility is a system census and configuration verification
tool that is also used to aid in diagnosing system errors and problems. Use
sys_check to create an HTML report of your system's configuration (software
and hardware). The size of the HTML output that is produced by the
sys_check utility is usually between .5 MB and 3 MB.
The sys_check utility also performs an analysis of operating system parame-
ters and attributes such as those that tune the performance of the system.
The report generated by sys_check provides warnings if it detects problems
with any current settings. Note that while sys_check can generate hundreds
of useful warnings, it is not a complete and definitive check of the health
of your system. The sys_check utility should be used in conjunction with
event management and system monitoring tools to provide a complete overview
and control of system status. Refer to EVM(5) for infor-
mation on event management. Refer to the System Administration guide for
information on monitoring your system.
When used as a component of fault diagnosis, sys_check can reduce system
down time by as much as 50% by providing fast access to critical system
data. It is recommended that you run a full check at least once a week to
maintain the currency of system data. However, note that some options will
take a long time to run and can have an impact on system performance. You
should therefore choose your options carefully and run them during off-peak
hours. At a minimum, perform at least one full run (all data and warnings)
as a post-configuration task in order to identify configuration problems
and establish a configuration baseline. The following table provides guide-
lines for balancing data needs with performance impact.
___________________________________________________________________________
Option Run time Performance Recommended At
impact
___________________________________________________________________________
-warn, -perf Short. Minimal. Regular
updates, at
least weekly
null - no options Medium, perhaps Some likely at Run at least
selected. 15 to 45 minutes peak system use. once post-
depending on pro- installation
cessor. and update
after major
configuration
changes. Update
your initial
baseline and
check warnings
regularly.
-noquick, -all, Long, perhaps 45 Very likely at Use only when
-escalate. minutes on fast, peak use. troubleshooting
large systems to a system prob-
hours on low-end lem or escalat-
systems. ing a problem
to your techni-
cal support
representative.
___________________________________________________________________________
You can run some sys_check options from the SysMan Menu or the
/usr/sbin/sysman -cli command-line interface. Choose one of the following
options from the menu:
>- Support and Services
| Create escalation report [escalation]
| Create configuration report [config_report]
Alternatively, use the config_report and escalation accelerators from the
command line. Note that the escalation option should only be used in con-
junction with a technical support request.
The runsyscheck script will run sys_check as a cron task automatically if
you do not disable the crontab entry in /var/spool/cron/crontabs/root.
Check for the presence of an automatically generated log file before you
create a new log as it may save time.
When you run the sys_check utility without command options, it gathers con-
figuration data excluding the setld scan and the security information and
displays the configuration and performance data by default. It is recom-
mended that you do this at least once soon after initial system configura-
tion to create a baseline of system configuration, and to consider perform-
ing any tuning recommendations.
On the first run, the sys_check utility creates a directory named
/var/recovery/sys_check. On subsequent runs, sys_check creates additional
directories with a sequential numbering scheme:
+ The previous sys_check directory is renamed to
/var/recovery/sys_check.0 while the most recent data (that is, from
the current run) is always maintained in /var/recovery/sys_check.
+ Previous sys_check directories are renamed with an incrementing exten-
sion; /var/recovery/sys_check.0 becomes /var/recovery/sys_check.1, and
so on, up to /var/recovery/sys_check.5.
There is a maximum of seven directories. This feature ensures that you
always have up to seven sets of data automatically. Note that if you only
perform a full run once, you may want to save the contents of that direc-
tory to a different location.
Depending on what options you choose, the /var/recovery/sys_check.*
directories will contain the following data:
+ Catastrophic recovery data, such as an etc files directory, containing
copies of important system files. In this directory, you will find
copies of files such as /etc/group, /etc/passwd, and /etc/fstab.
+ Formatted stanza files and shell scripts and that you can optionally
use to implement any configuration and tuning recommendations gen-
erated by asys_check run. You use the sysconfigdb command or run the
shell scripts to implement the stanza files. See the sysconfigdb(8)
reference page for more information.
NOTES
You must be root to invoke the sys_check utility from the command line;
you must be root or have the appropriate privileges through Division of
Privileges (DoP) to run Create Configuration Report and Create Escalation
Report from the SysMan Menu. The sys_check utility does not change any sys-
tem files.
The sys_check utility is updated regularly. You can obtain the latest ver-
sion of the sys_check utility from either of two sources:
+ The most up-to-date version of the sys_check kit is located on the
sys_check tool web site,
http://www.tru64unix.compaq.com/sys_check/sys_check.html.
+ You can also obtain sys_check from the patch kit, see
http://www.support.compaq.com/patches/.
You should run only one instance of sys_check at a time. The sys_check
utility prevents the running of multiple instances of itself, provided that
the value of the TMPDIR environment variable is /var/tmp, /usr/tmp, /tmp,
or a common user-defined directory. This avoids possible collisions when
an administrator attempts to run sys_check while another administrator is
already running it. However, no guarantees can be made for the case when
two administrators set their TMPDIR environment variables to two different
user-defined directories (this presumes that one administrator does not
choose /var/tmp, /usr/tmp, or /tmp).
The sys_check utility does not perform a total system analysis, but it does
check for the most common system configuration and operational problems on
production systems.
Although the sys_check utility gathers firmware and hardware device revi-
sion information, it does not validate this data. This must be done by
qualified support personnel.
The sys_check utility uses other system tools to gather an analyze data. At
present, sys_check prefers to use DECevent, and you should install and con-
figure DECevent for best results.
If DECevent is not present, the sys_check utility issues a warning message
as a priority 500 EVM event and attempts to use uerf instead. In future
releases, Compaq Analyze will also be supported on certain processors.
Note that there are restrictions on using uerf, DECevent and Compaq Analyze
that apply to:
+ The version of UNIX that you are currently using.
+ The installed version of sys_check.
+ The type of processor.
EXIT STATUS
The following exit values are returned:
0 Successful completion.
>0 An error occurred.
LIMITATIONS
DECevent or Compaq Analyze may not be able to read the binary error log
file if old versions of DECevent are being used or if the binary.errlog
file is corrupted. If this problem occurs, install a recent version of
DECevent and, if corrupted, recreate the binary.errlog file.
HSZ controller-specific limitations include the following:
HSZ40 and HSZ50 controllers:
The sys_check utility uses a free LUN on each target in order to com-
municate with HSZ40 and HSZ50 controllers. To avoid data gathering
irregularities, always leave LUN 7 free on each HSZ SCSI target for
HSZ40 and HSZ50 controllers.
HSZ70, HSZ80 and G80 controllers:
The sys_check utility uses a CCL port in order to communicate with
HSZ70 controllers. If a CCL port is not available, sys_check will use
an active LUN. To avoid data gathering irregularities, enable the CCL
port for each HSZ70 controller.
The sys_check utility attempts to check the NetWorker backup schedule
against the /etc/fstab file. For some older versions of NetWorker, the
nsradmin command contains a bug that prevents sys_check from correctly
checking the schedule. In addition, the sys_check utility will not
correctly validate the NetWorker backup schedule for TruCluster Server.
EXAMPLES
1. The following command creates escalation files that are used to report
problems to your technical support organization:
# sys_check -escalate
2. The following command outputs configuration and performance informa-
tion, excluding security information and the setld inventory, and pro-
vides an analysis of common system configuration and operational prob-
lems:
# sys_check > file.html
3. The following command outputs all information, including configura-
tion, performance, and security information and a setld inventory of
the system:
# sys_check -all > file.html
4. The following command outputs only performance information:
# sys_check -perf > file.html
5. The following command provides HTML output with frames, including con-
figuration and performance information and the setld inventory of the
system:
# sys_check -frame -noquick
6. The following command starts the SysMan Menu config_report task from
the command line:
# /usr/sbin/sysman config_report
Entering this command invokes the SysMan Menu, which prompts you to
supply the following optional information:
+ Save to (HTML) - A location to which the HTML report should be
saved, which is /var/adm/hostname_date.html by default.
+ Export to Web (Default) - Export the HTML report to Insight
Manager. Refer to the System Administration manual for information on
Insight Manager.
+ Advanced options - This option displays another screen in which
you can choose a limited number of run time options. The options
are equivalent to certain command-line options listed in the
OPTIONS section.
In this screen, you can also specify an alternate temporary
directory other than the default of /var/tmp.
+ Log file - The location of the log file, which is
/var/adm/hostname_date.log by default.
7. The following is an example of a stanza file advfs.stanza in
/var/recovery/sys_check.*:
advfs:
AdvfsCacheMaxPercent=8
8. The following is an example of a shell script apply.kshin
/var/recovery/sys_check.*:
cd /var/cluster/members/member/recovery/sys_check/
llist="advfs.stanza
vfs.stanza "
for stf in $llist; do
print " $stf "
stanza=`print $stf | awk -F . '{print $1 }'`
print "/sbin/sysconfigdb -m -f $stf $stanza"
/sbin/sysconfigdb -m -f $stf $stanza
done
print "The system may need to be rebooted for these
changes to take effect"
ENVIRONMENT VARIABLES
The following environment variables affect the execution of the sys_check
utility. Normally, you only change these variables under the direction of
your technical support representative, as part of a fault diagnosis pro-
cedure.
TMPDIR
Specifies a default parent directory for the sys_check working sub-
directory, whose name is randomly created; this working subdirectory is
removed when sys_check exits. The default value for TMPDIR is /var/tmp.
LOGLINES
Specifies the number of lines of log file text that sys_check includes
in the HTML output. The default is 500 lines.
BIGNUMFILE
Specifies the number of files in a directory, above which a directory
is considered excessively large. The default is 15 files.
BIGFILE
Specifies the file size, above which a file is considered excessively
large. The default is 3072 KB.
VARSIZE
Specifies the minimum amount of free space that sys_check requires in
the TMPDIR directory. The default is 15 MB and should not be reduced.
The sys_check utility will not run if there is insufficient disk space.
RECOVERY_DIR
Specifies the location for the sys_check recovery data. The default is
/var/recovery. The sys_check utility automatically cleans up data from
previous command runs. The typical size of the output generated by
each sys_check utility run is 400 KB. This data may be useful in
recovering from a catastrophic system failure.
ADHOC_DIR
Specifies the location at which sys_check expects to find the text
files to include in the HTML output. The default is the /var/adhoc
directory.
TOOLS_DIR
Specifies the location at which sys_check expects to find the binaries
for the tools that it calls. The default is /usr/lbin.
FILES
/usr/sbin/sys_check
Specifies the command path.
Note
This file may be a symbolic link.
/usr/lbin/*
Various utilities in this directory are used by sys_check.
Note
These files may be symbolic links.
The sys_check utility reads many system files.
SEE ALSO
Commands: dop(8), sysconfigdb(8), sysman_cli(8), sysman_menu(8)
Miscellaneous: EVM(5), insight_manager(5)
Books: System Administration, System Tuning
1.15 Release Notes for Tru64 UNIX Patch 737.00
This section contains release notes for Patch 737.00.
1.15.1 Updates to sh, csh, and ksh
The updated shells in this kit all implement the following changes when processing shell inline input files:
File permissions allow only read and write for owner.
If excessive inline input file name collisions occur, the following error message will be returned:
Unable to create temporary file
1.15.2 sh noclobber Option and >| , >>| Constructs Added
A
noclobber
option similar to that already available
with
csh
and
ksh
has been added to
the Bourne shell.
When the
noclobber
option is used (set -C), the shell behavior for the redirection operators
>
and
>>
changes as follows:
For
>
with
noclobber
set,
sh
will return an error rather than overwrite
an existing file.
If the specified file name is actually a symbolic
link, the presence of the symbolic link satisfies the criteria
file exists
whether or not the symbolic link target exists
and
sh
returns an error.
The
>|
construct will suppress these checks and create the file.
For
>>
with
noclobber
set, output is appended to the tail of an existing file.
If the
file name is actually a symbolic link whose target does not exist,
sh
returns an error rather than create the file.
The
>>| construct will suppress these checks and create the
file.
1.15.3 ksh noclobber Behavior Clarified
For
>
with
noclobber
set,
ksh
will return an error rather than overwrite an existing
file.
If the specified file name is actually a symbolic link, the
presence of the symbolic link satisfies the criteria
file
exists
whether or not the symbolic link target exists
and
ksh
returns an error.
The
>|
construct
will suppress these checks and create the file.
For
>>
with
noclobber
set, output
is appended to the tail of an existing file.
If the file name is actually
a symbolic link to a nonexistent file,
ksh
returns an
error.
This is a behavior change.
Because
ksh
does not
have a
>>|
redirection override, create the symbolic link
target before accessing it through
>>
if you depend upon
appending through a symbolic link.
1.15.4 csh noclobber Behavior Clarified
For
>
with
noclobber
set,
csh
will return an error rather than overwrite an existing
file.
If the specified file name is actually a symbolic link, the
presence of the symbolic link satisfies the criteria
file
exists
whether or not the symbolic link target exists,
and
csh
returns an error.
The
>|
construct
will suppress these checks and create the file.
For
>>
with
noclobber
set, output
is appended to the tail of an existing file.
If the file does not
exist, or the file name is actually a symbolic link whose target
does not exist,
csh
returns an error rather than
create the file.
The
>>|construct will suppress
these checks and create the file.
1.15.5 Updated mkdir System Call and Command
This kit reverts the
mkdir
system call, and thus
the
mkdir
command, to its Tru64 UNIX Version 4.n behavior
with respect to symbolic links.
For the unusual case where a symbolic link
is used as the very last element of a
mkdir
path, the
mkdir
system call now returns an error than create the target.
If you want
mkdir
to follow the symbolic link you
can do so by making the last character of the
mkdir
pathname
a slash.
For example, if
/var/tmp/foo
is a symbolic link
to
/usr/xxx, which does not exist, then
/mkdir("/var/tmp/foo",0644)
will return an error but
mkdir("var/tmp/foo/",0644)
will create
/usr/xxx.
The behavior of
mkdir
can also be controlled systemwide
by an addition to the
sysconfig
options for the
vfssubsystem.
The new
sysconfig
option
follow_mkdir_symlinks
defaults to 0, specifying the secure symbolic
link behavior.
Changing this option to 1, which we strongly discourage,
will cause
mkdir
to follow symbolic links.
1.16 Release Note for Tru64 Patch 504.00
This release note contains updates to the
sys_attrs_netrain
(5),
nifftmt
(7),
niffconfig(8),
and
ifconfig(8) reference pages.
sys_attrs_netrain(5)
nr_timeout_dead_interface
The time interval or frequency between successive polls of a dead
interface by the NetRAIN interface recovery thread.
Minimum value: 0.5 (seconds)
nr_timeout_o
Minimum value: 1.1
nr_timeout_t
Minimum value: 0.5
You can specify decimal values (for example, 2.5 or 0.8) for
nr_timeout_dead_interface, nr_timeout_o, and nr_timeout_t. When you recon-
figure any of these values by using the sysconfig -r command, they are all
validated together. If any value fails validation, all previous (valid)
values are restored and EINVAL is returned. Each value must be greater than
or equal to its minimum value.
The nr_timeout_o and nr_timeout_t values are validated in conjunction with
a third timer value (dt), calculated as (nr_timeout_t - nr_timeout_o) / 3.
These 3 timer values are validated as described in nifftmt(7).
SEE ALSO
sys_attrs(5), nifftmt(7)
Network Administration: Connections
nifftmt(7)
The time_to_dead field (shown in the EXAMPLES section and in
niffconfig -v) is the amount of time that expires between the
red alert being raised and the interface being declared dead. It
is calculated by the traffic monitor thread as t2 - t1 - (2 *
dt).
You can specify the values for t1, dt, and t2 in seconds (if the
MIF_MILLISECONDS bit is clear in the flags field), or in milliseconds (if
the MIF_MILLISECONDS bit is set). See the EXAMPLES section to see how this
is used.
The traffic monitor thread enforces the following restriction between the
timing parameters:
t2 >= t1 + 2dt
t1 >= 0.5
t2 >= 1.1
dt >= 0.2
In the preceding restrictions, the values for t1, dt, and t2 are in
seconds.
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <sys/param.h>
#include <net/if.h>
#include <errno.h>
/* these strings map to the "state" enum */
char *state[] = {"INIT", "GREEN", "YELLOW", "ORANGE", "RED", "DEAD"};
/* usage: niff_example tu0 tu1 tu2...
* must supply the name of at least one
* network interface
*/
main(int ac, char **av)
{
int t1 = 20, t2 = 60, dt = 5;
char **oldav;
mif_t mif;
int s;
oldav = ++av;
s = socket(AF_INET, SOCK_DGRAM, 0);
/* tell the traffic monitor to start watching these interfaces */
while (*av) {
printf("Adding interface %s to the traffic monitor\n", *av);
bzero(&mif, sizeof (mif));
bcopy(*av, &mif.name[0], MIN(strlen(*av)+1, sizeof(mif.name)-1));
mif.t1 = t1;
mif.t2 = t2;
mif.dt = dt;
mif.flags = 0;
if (ioctl(s, SIOCTMTADD, &mif) < 0) {
perror("couldn't add interface");
break;
}
++av;
}
av = oldav;
/* get the status of the interfaces - NB will probably always
* be in the "init" state
*/
while (*av) {
printf("checking the status of interface %s\n", *av);
bzero(&mif, sizeof (mif));
bcopy(*av, &mif.name[0], MIN(strlen(*av)+1, sizeof(mif.name)-1));
if (ioctl(s, SIOCTMTSTATUS, &mif) < 0) {
perror("couldn't get status for interface");
break;
} else {
printf("Interface: %05s, state: %s ", mif.name,
state[miff.current_state]);
if (mif.flags & MIF_MILLISECONDS)
printf("Timer values in milliseconds...\n");
else
printf("Timer values in seconds...\n");
printf("t1: %d, dt: %d, t2: %d, time to dead: %d,
current_interval:%d, next time: %d\n",
mif.t1, mif.dt, mif.t2, mif.time_to_dead, mif.current_interval,
mif.next_time);
}
++av;
}
av = oldav;
/* tell the traffic monitor to stop watching */
while (*av) {
printf("deleting interface %s from the traffic monitor0, *av);
bzero(&mif, sizeof (mif));
bcopy(*av, &mif.name[0], MIN(strlen(*av)+1, sizeof(mif.name)-1));
if (ioctl(s, SIOCTMTREMOVE, &mif) < 0) {
perror("couldn't remove interface");
}
++av;
}
exit(0);
}
niffconfig(8)
SYNOPSIS
/usr/sbin/niffconfig [-a] [-m] [-r] [-s] [-u] [-v] [-d dt] [-o t2] [-t t1]
[interface1 interface2...]
-d dt
Specifies the time period, in seconds, that the traffic monitor thread
uses between reads of the interface counters when it suspects there is
a connectivity problem. This number must be smaller than the number
given for t1 (see the -t option). The default time period is 5 seconds.
If dt is not specified, niffconfig uses the default.
-o t2
Specifies the total number of traffic-free seconds that must elapse
before the traffic monitor thread determines that a network interface
has failed. This number must be at least the sum of the t1 and two
times dt. That is, given the default time period for dt (5 seconds)
and t1 (20 seconds), the t2 value must be at least 30 seconds. The
default time period for t2 is 60 seconds. If t2 is not specified,
niffconfig uses the default.
-m Modifies the timing parameters of an interface that is already being
monitored. Typically, this option is specified along with one or more
of -t t1, -d dt, or -o t2 options. If none of these parameters are
specified, the default value is used. You cannot specify the -m option
with the -a, -s, -r, -u, or -v options.
-t t1
Specifies the time period, in seconds, that the traffic monitor thread
delays between reads of the interface counters when the network is run-
ning normally. The default time period is 20 seconds. If t1 is not
specified, niffconfig uses the default.
-v Displays the status, timer values, and description (verbose mode) of
all interfaces currently being monitored to standard out (stdout). See
nifftmt(7) for a definition of each of the parameters.
Except for the -u and -v options, all niffconfig options require one or
more network interfaces to be specified.
You can specify the t1, dt, and t2 timer values as decimal values (for
example, 2.6 or 0.8). When setting timer values with the -a or -m options,
all three timer values (t1, dt, and t2) are validated as described in
nifftmt(7). If the validation fails, the operation is cancelled and a mes-
sage is printed t o stdout.
NetRAIN initiates its own internal interface monitoring (using NIFF) when a
NetRAIN set is created. NetRAIN monitored interfaces are visible only with
the -v option. You cannot use niffconfig to perform any other management
operations on the NetRAIN interfaces. To modify the timer values for
NetRAIN monitored interfaces, use the ifconfig command.
You can start additional monitoring of an interface that is already being
monitored internally for NetRAIN. In that case, the niffconfig -v command
will display the two different monitoring structures for the interface.
All other niffconfig options will operate only on the non-NetRAIN monitor-
ing structure.
EXAMPLES
5. To display all parameters for all interfaces that are being monitored,
including NetRAIN interface monitoring, enter:
# niffconfig -v
ifconfig(8)
The
monitor
section should be removed:
The following is added after the second paragraph of the
nrtimers
section:
You can specify decimal values for both the t1 and t2 parameters (for
example, 1.5 or 0.8). If you do this, the values are validated simi-
larly to the nr_timeout_t and nr_timeout_o kernel attributes. See
sys_attrs_netrain(5) for more information on minimum and maximum
NetRAIN timer values.
1.17 Release Note for Tru64 UNIX Patch 846.00
This section contains release notes for Tru64 UNIX Patch 846.00.
1.17.1 Enabling the /dev/poll Function
In order to enable the
/dev/poll
function the special
device
poll
must be created manually.
The procedure is
as follows:
Change your directory to
/dev:
#
cd /dev
Execute the MAKEDEV script, found in that directory with either
poll
or
std
as an argument:
#
MAKEDEV [poll or std]
1.17.2 Removal of Version-switched patch
This patch provides a script,
/usr/sbin/evm_versw_undo,
that allows you to remove the EVM patch after the version switch has been
thrown by running
clu_upgrade -switch.
This script will
set back the version identifiers and request a cluster shutdown and reboot
to finish the deletion of the patch.
Another rolling upgrade will be required
to delete the patch with
dupatch.
Note
Because the removal of a version-switched patch requires a cluster shutdown, only run this script when you are absolutely sure that this patch is the cause of your problem.
This script must be run by root in multiuser mode after completing the rolling upgrade that installed the patch and before starting another rolling upgrade. The final removal of the patch can only be accomplished by rebooting the system or cluster after this script completes its processing. This script will offer to shut down your system or cluster at the end of its processing. If you choose to wait, it is your responsibility to execute the shutdown of the system or cluster.
Do not forget or wait for an extended period of time before shutting down the cluster. Cluster members that attempt to reboot before the entire cluster is shut down can experience panics or hangs.
This patch adds a new
ee
subsystem attribute,
link_check_interval, that allows the
ee
driver
link state polling interval to be tuned for faster failover times when using
ee
devices for Link Aggregation.
The
sys_attrs_ee(5) reference page is updated as
follows:
link_check_interval
The interval at which the driver polls the interface link
state, in units of hundredths of seconds. Modifying this
interval is recommended only when using "ee" devices for
Link Aggregation.
Default value: 200 (2 seconds)
Minimum value: 10 (0.1 seconds)
Maximum value: 1000 (10 seconds)
1.17.4 lag(7) Reference Page Update
This patch enables support for network Link Aggregation, or trunking. Link Aggregation can be used to provide increased network bandwidth and availability. Two or more physical Ethernet ports can be combined to create a link aggregation group, which is seen by upper-layer software as a single logical network interface.
See the
Network Administration: Connections
manual
for information on configuring link aggregation groups.
See
lag(7) and
lagconfig(8) for more information
about link aggregation.
lag(7) lag(7)
NAME
lag - Link aggregation (also called trunking) introductory information
DESCRIPTION
Link aggregation, or trunking, enables administrators to combine two or
more physical Ethernet Network Interface Cards (NICs) and create a single
virtual link. (Upper-layer software sees this link aggregation group as a
single virtual interface.) The single virtual link can carry traffic at
higher data rates than a single interface because the traffic is distri-
buted across all of the physical ports that make up the link aggregation
group.
Using link aggregation provides the following capabilities:
o Increased network bandwidth - The increase is incremental based on the
number and type of ports, or Network Interface Cards (NICs), added to
the link aggregation group. See the "Load Sharing" section for more
information.
o Fault tolerance - If a port in a link aggregation group fails, the
software detects the failure and reroutes traffic to the other avail-
able ports. See the "Fault Tolerance" section for more information.
o Load sharing - Traffic is distributed across all ports of a link
aggregation group. See the "Load Sharing" section for more informa-
tion.
You can use a link aggregation group virtual interface for the following
point-to-point connections: server-to-server and server-to-switch. For
server-to-switch connections, the switch must support link aggregation.
See your switch documentation for information on configuring your switch.
Link aggregation requires an optional kernel subsystem (lag.mod). You can
verify the presence of the link aggregation subsystem by issuing the
sysconfig -s lag command. If the lag subsystem is not loaded, you can
load it using either of the following methods:
o Dynamically load it using the sysconfig -c lag command. This method
does not persist across system reboots.
o Edit the system configuration file, add an options LAG entry to it,
and build a new kernel by issuing the doconfig command. Then, reboot
the system. This method loads the subsystem each time the system
reboots.
After the subsystem is loaded, you can configure a link aggregation group.
Link Aggregation Configuration
You can configure link aggregation groups either in multiuser mode or at
boot time with the lagconfig command. When you configure the group, you
can specify a virtual interface number, a key, a distribution algorithm,
and a Media Access Control (MAC) address.
After you create a link aggregation group, you can then enable ports
(interfaces) for link aggregation. The enabled ports attach to the link
aggregation group with the corresponding key. If the port fails in some
way, the port detaches from the group and traffic is rerouted to the
remaining port or ports.
Any link aggregation configuration done in multiuser mode does not persist
across system reboots. If you want link aggregation groups configured at
boot time, you must include the appropriate lagconfig and ifconfig commands
in the the /etc/inet.local file. See the Network Administration: Connec-
tions manual for an example.
On platforms where I/O bandwidth may be a limiting factor, you might
increase link aggregation performance by distributing the NICs across dif-
ferent portions of the I/O infrastructure (for example, different PCI
buses).
Fault Tolerance
The link aggregation subsystem monitors the link state of ports that are
enabled for link aggregation. When the link aggregation subsystem detects
that a port's link state is down, the subsystem detaches the port from its
link aggregation group and redistributes traffic among the remaining ports.
When the link aggregation subsystem detects that the port's link state is
up, the subsystem reattaches the port to its link aggregation group. The
port then starts handling part of the traffic load again. The amount of
time it takes to detect a link state change and fail over depends on the
device and driver in use. For DE60x devices using the ee driver in its
default configuration, average failover times are on the order
of 1 to 2 seconds. To achieve faster failover, reduce the value of the ee subsystem
link_check_interval attribute. A value of 20 (0.2 seconds) would
provide average failover times are on the order of 0.1 to 0.2 seconds.
For DEGPA devices using the alt driver, average failover times are less than 1 second.
Load Sharing
A link aggregation group performs load sharing of both inbound and outbound
traffic. Distribution of inbound packets is determined by the server or
switch to which the link aggregation group is connected. When transmitting
packets, the system uses a load distribution algorithm to determine on
which attached port to transmit the packets. The following load distribu-
tion algorithms are supported:
Destination IP Address (dstip)
For IP packets, the port is selected based on a hash of the destination
IP address. For non-IP packets, the port is selected based on a hash
of the destination MAC address. All traffic addressed to a specific
destination IP address uses the same port in the link aggregation
group.
This algorithm can utilize the combined bandwidth of a link aggregation
group in environments where traffic is destined to a large number of
different IP addresses (for example, a web server).
However, this algorithm might not produce the expected bandwidth utili-
zation in environments where the majority of traffic is destined to a
single IP address (for example, a private server-to-server intercon-
nect).
Destination MAC address (dstmac)
The port is selected based on a hash of the destination MAC address.
All traffic addressed to a specific destination MAC address uses the
same port in the link aggregation group.
This algorithm can utilize the combined bandwidth of a link aggregation
group in environments where traffic is destined to a large number of
different MAC addresses (for example, a server that sends most of its
traffic to clients on the same LAN).
However, this algorithm might not produce the expected bandwidth utili-
zation in environments where the majority of traffic is destined to a
small number of MAC addresses (for example, a server-to-server inter-
connect, or a server that sends most of its traffic through a router).
Transport Port number (port)
For TCP or UDP packets originating on the system, the port is selected
based on a hash of the source and destination TCP or UDP port numbers.
For all other packets, including TCP and UDP packets being forwarded by
the system, the Destination IP address (dstip) algorithm is used. All
traffic addressed to a specific source+destination port pair uses the
same port in the link aggregation group.
This algorithm can utilize the combined bandwidth of a link aggregation
group in environments where traffic is destined to a single IP or MAC
address, but is exchanged between a number of different TCP or UDP port
number pairs (for example, a server-to-server interconnect).
Round Robin (roundrobin)
The port is selected on a rotating basis.
This algorithm can utilize the combined bandwidth of a link aggregation
group in most environments.
However, this algorithm may result in reordering of packets belonging
to the same flow (for example, a TCP connection), which in turn may
adversely affect performance.
RESTRICTIONS
The following restrictions apply:
o Supports only DEGPA (alt) and DE60x (ee) network interface cards
(NICs).
o Supports only Ethernet (802.3 CSMA/CD) links.
o Ports must be operating in full duplex mode.
o Ports in the same link aggregation group must operate at the same data
rate.
o Ports in a link aggregation group must be attached to the same system,
either server-to-server or server-to-switch.
RELATED INFORMATION
Commands: lagconfig(8)
System Attributes: sys_attrs_lag(5)
Files: inet.local(4)
Technical Overview
Network Administration: Connections
1.17.5 lagconfig(8) Reference Page Update
lagconfig(8) lagconfig(8)
NAME
lagconfig - Configures or displays link aggregation groups (or trunk
groups)
SYNOPSIS
For creating a link aggregation group, use the following syntax:
/usr/sbin/lagconfig -c [attribute,attribute,...]
For enabling a port for link aggregation, use the following syntax:
/usr/sbin/lagconfig -p port {lag=interface-id | key=value}
For deleting a port from a link aggregation group, use the following syn-
tax:
/usr/sbin/lagconfig -d port
For displaying a link aggregation group, use the following syntax:
/usr/sbin/lagconfig -s lag=interface-id
OPTIONS
-c Creates a link aggregation group virtual interface. You can specify the
following attributes to this option. If you specify more than one
attribute, separate them with commas:
lag=interface-id
Specifies the link aggregation group virtual interface name in the
form lagn, where n is the unit number (for example, lag1). By
default, the next available unit number is assigned to the inter-
face.
key=value
Specifies a value with which to identify the link aggregation group
interface. By default, the key value is the next available number.
For example, if you previously created a link aggregation group
with a key of 4, the next time you create a link aggregation group
it is assigned a key of 5.
dist={dstip|dstmac|port|roundrobin}
Specifies the distribution algorithm to be used by the virtual
interface for outbound traffic. The software can distribute traffic
based on destination IP address (dstip), destination MAC address
(dstmac) or transport port number (port), or in a round robin
fashion (roundrobin). The default distribution algorithm is dstip.
See lag(7) for more information.
macaddr=address
Specifies the Media Access Control (MAC) address to be assigned to
the link aggregation group interface. By default, the MAC address
of the first link aggregation port (interface) to attach to the
link aggregation group is used.
-p port
Enables the specified port (or physical interface) for link
aggregation. You must also specify one of the following attributes:
lag=interface-id
Specifies the link aggregation group virtual interface name in the
form lagn, where n is the unit number (for example, lag1).
key=value
Specifies the link aggregation group virtual interface to which to
add the port by the key assigned to it.
-d port
Deletes the specified port or interface from a link aggregation group.
-s lag=interface-id
Displays the attributes for the specified link aggregation group. The
interface-id is in the form lagn, where n is the unit number (for exam-
ple, lag3).
DESCRIPTION
The lagconfig command allows you to perform the following tasks:
o Create link aggregation group virtual interfaces.
o Enable a port (physical interface) for link aggregation.
o Display attributes for a specified link aggregation group virtual
interface.
o Delete a port from a link aggregation group.
Link aggregation, or trunking, enables administrators to combine one or
more physical Ethernet Network Interface Cards (NICs) and create a single
virtual link. (Upper-layer software sees this link aggregation group as a
single virtual interface.) The single virtual link can carry traffic at
higher data rates than a single interface because the traffic is distri-
buted across all of the physical ports that make up the link aggregation
group.
If you want to enable a port for link aggregation, you must not configure
an IP address on the port, either through the Network Setup Wizard (netcon-
fig) or SysMan. After you enable ports for link aggregation, you issue the
ifconfig up command to enable the link aggregation group interface. The
enabled ports then attach to the link aggregation group that has the same
key assigned to it and are available to carry traffic.
If a port fails in some way, the port detaches from the link aggregation
group and traffic rerouted to the remaining port or ports. A port also
detaches when the system is shut down.
The server or switch at the other end of a link aggregation group must also
be configured for link aggregation.
Modifications made with the lagconfig command do not persist across reboots
of the operating system. To configure the interface or modify the parame-
ters automatically each time the system is booted, edit the inet.local file
and add the lagconfig command and ifconfig command entries to it.
Any user can query the status of a link aggregation group; only the
superuser can create and modify the configuration of network interfaces.
EXAMPLES
1. To create the link aggregation group virtual interface lag0 with key
value 1 and transport port-based distribution, enter:
lagconfig -c lag=lag0,key=1,dist=port
2. To add ee0 and ee1 to the link aggregation group created in the previ-
ous step, enter:
lagconfig -p ee0 key=1
lagconfig -p ee1 key=1
Note
Both ee0 and ee1 must be DOWN and not have an IP address configured
prior to issuing the lagconfig -p commands.
3. To display information about the link aggregation group, enter:
lagconfig -s lag=lag0
lag0: Attached Interfaces: ( ee3 ee2 ee1 ee0 )
key = 1
Max ports = 8
dist = port
4. To configure an IP address 10.1.2.3 on the link aggregation group vir-
tual interface lag0 and bring the interface up, enter:
ifconfig lag0 10.1.2.3 up
DIAGNOSTICS
lagconfig: subsystem error: Invalid argument
You attempted to add a port (interface) to a link aggregation group and
the port is UP. Mark the interface DOWN with the ifconfig command and
try to add the port again.
SEE ALSO
Commands: netstat(1), ifconfig(8), pfconfig(8), sysconfig(8)
Interfaces: lag(7)
System Attributes: sys_attrs_lag(5)
Network Administration: Connections
1.17.6 wol(8) Reference Page Update
This release note contains updates to the
wol(8)
reference page.
wol(8)
NAME
wol - Send network packet to power on target system (wake-on-LAN)
SYNOPSIS
/usr/sbin/wol [nw_interface] hw_address
OPTIONS
nw_interface
Specifies the network interface to use in making the connection to the
target system, for example: tu1. This argument is optional.
OPERANDS
hw_address
Specifies the hardware network address of the target system, for exam-
ple: 00-02-56-00-03-29. This argument is mandatory.
DESCRIPTION
The wol utility generates and transmits a network packet to power on a
remote system. Before you can use the wol utility, you must enable the
remote system management wake-on-LAN feature on the target system.
You must specify the target system's hardware address. You may optionally
specify the network interface to use in making the connection to the target
system. If no network interface is specified, the wol utility locates the
first configured network interface and prompts you for confirmation.
To enable the wake-on-LAN feature, set the target system's wol_enable con-
sole variable to on and reset the system so that the network controller can
read the new state. Use one of the following methods to enable this feature
on the target system:
+ From the target system's console prompt. enter the following commands:
>>> set wol_enable on
>>> init
+ From the target system's UNIX root prompt, enter the following com-
mands:
% consvar -s wol_enable on
set wol_enable = on
% consvar -a
Console environment variables saved
% reboot
Use one of the following methods to disable the wake-on-LAN feature:
+ From the target system's console prompt. enter the following commands:
>>> set wol_enable off
>>> init
+ From the target system's UNIX root prompt, enter the following commands:
% consvar -s wol_enable off
set wol_enable = on
% consvar -a
Console environment variables saved
% reboot
Note
You must reset the target system for the new setting to take effect.
RESTRICTIONS
You must be logged in as root or have superuser privileges to use the wol
utility.
The wake-on-LAN feature is only available on specific platforms. On plat-
forms that support this feature, additional restrictions may apply. For
example, the wake-on-LAN feature may be supported on specific network
interface ports only. See your hardware documentation for additional infor-
mation.
EXIT STATUS
0 (Zero)
Success.
>0 An error occurred.
ERRORS
+ Error detecting default interface
Explanation:
The wol utility cannot automatically detect a default network inter-
face.
User Action:
-- Verify that a configured network interface exists on your system.
-- Manually specify a configured network interface on the wol com-
mand line.
+ Patterns must be specified as hex digits The Magic Packet address must
be specified as 00-11-22-33-44-55
Explanation:
The hardware network address entered was in the wrong format. This
argument must be in the following format: xx-xx-xx-xx-xx-xx, where x
is a hexadecimal character (0 through 9 and A through F, inclusive).
User Action:
Specify the hardware network address correctly.
EXAMPLES
1. The following example shows a simple use of the wol utility, where the
host system detects the first configured network interface and prompts
for confirmation:
# /usr/sbin/wol 00-02-56-00-03-29
No sending device specified, using tu0, continue? (y/n) y
2. The following example shows the same use of the wol utility, where the
user declines confirmation of the selected network interface:
# /usr/sbin/wol 00-02-56-00-03-29
No sending device specified, using tu0, continue? (y/n) n
Aborting...
3. The following example explicitly specifies a network interface:
# /usr/sbin/wol tu1 00-02-56-00-03-29
ENVIRONMENT VARIABLES
wol_enable
Enables or disables the wake-on-LAN feature on the target system. Valid
values are on and off.
Note
This is a system console variable, not a UNIX environment variable.
The DESCRIPTION section tells you how to enable the wake-on-LAN
feature on the target system. You must enable this feature before
you use the wol utility.
FILES
/usr/sbin/wol
Wake-on-LAN utility.
SEE ALSO
Commands: consvar(8), halt(8), reboot(8), shutdown(8)
New Hardware Delivery Release Notes and Installation Instructions
System Administration
1.18 Release Note for TruCluster Patch 9.00
This release note explains the relaxed
Cluster Alias: gated
restriction.
Prior to this patch, we required that you use
gated
as a routing daemon for the correct operation of cluster alias routing because
the cluster alias subsystem did not coexist gracefully with either the
routed
or static routes.
This patch provides an
aliasd
daemon that does not depend on having
gated
running in order to function correctly.
The following is a list of features supported by this patch:
The
gated
and
routed
routing daemons are supported in a cluster.
In addition, static routing is
supported (no routing daemons are required).
Because
aliasd
is optimized for
gated,
using
gated
remains the default and preferred routing daemon.
However, it is no longer mandatory, nor is it the only way to configure routing
for a cluster member.
For example, you could configure a cluster where all
members use static routing, or some members run
routed,
or use a combination of routing daemons and static routes.
However, the exisiting restriction against using
ogated
still applies; do not use
ogated
as a routing daemon in
a cluster.
Note
Cluster members do not have to have identical routing configurations. In general, it is simpler to configure all cluster members identically, but in some instances, an experienced cluster administrator might choose to configure one or more members to perform different routing tasks. For example, one member might have
CLUAMGR_ROUTE_ARGS="nogated"in its/etc/rc.configfile and have a fully populated/etc/routesfile. Or a member might run withnogatedandrouted -q.
The alias daemon
The alias daemon will handle the failover of cluster alias IP addresses
via the cluster interconnect for either dynamic routing or static routing.
If an interface fails,
aliasd
reroutes alias traffic to
another member of the cluster.
As long as the cluster interconnect is working,
there is always a way for cluster alias traffic to get in or out of the cluster.
Interface IP aliases
The
cluamgr
command supports two new
-r
options,
ipalias
and
noipalias.
These options control whether
aliasd
on a member system
monitors interface IP aliases.
These options let an administrator determine
whether a script or
aliasd
manages these interface IP aliases.
When
ipalias
is set,
aliasd
monitors
and manages interface IP aliases.
When
noipalias
is set,
aliasd
does not monitor or manage IP interface aliases.
The default
setting is
noipalias.
Notes
If you use scripts (for example, CAA action scripts) to configure and relocate interface IP aliases for some or all cluster members, run
cluamgr -r noipaliason those members.You cannot tell
aliasdto watch some interface IP aliases on a system but ignore others.
Multiple interfaces per subnet (for network load balancing)
Although
gated
does not support this configuration,
because static routing is supported, an administrator can use static (nogated) routing for network load balancing.
By default, the cluster alias subsystem uses
gated,
customized configuration files (/etc/gated.conf.member<n>), and RIP to advertise host routes for alias
addresses.
You can disable this behavior by specifying the
nogated
option to
cluamgr, either by running the
cluamgr -r nogated
command on a member or by setting
CLUAMGR_ROUTE_ARGS="nogated"
in that members
/etc/rc.config
file.
For example,
the network configuration for a member could use
routed,
or
gated
with a site-customized
/etc/gated.conf
file, or static routing.
For a cluster, there are three general routing configuration scenarios:
The default configuration:
aliasd
controls
gated.
Each member has the following in its
/etc/rc.config
file:
GATED="yes" CLUAMGR_ROUTE_ARGS="" # if variable present, set to a null string
If needed, static routes are defined in each member's
/etc/routes
file.
Note
Static routes in
/etc/routesfiles are installed before routing daemons are started, and honored by routing daemons.
Members run
gated, but the cluster alias
and
aliasd
are independent of it.
The administrator has
total control over
gated
and its configuration file,
/etc/gated.conf.
This approach is useful for an administrator who
wants to enable IP forwarding and configure a member as a full-fledged router.
Each member that will follow this policy has the following
in its
/etc/rc.config
file:
GATED="yes" CLUAMGR_ROUTE_ARGS="nogated" ROUTER="yes" # if this member will be a full-fledged router
If needed, configure static routes in
/etc/routes.
Static routing: one or more cluster members do not run a routing daemon.
Each member that will use static routing has the following
in its
/etc/rc.config
file:
GATED="no" CLUAMGR_ROUTE_ARGS="nogated" ROUTED="no" ROUTED_FLAGS=""
Define static routes in that member's
/etc/routes
file.
1.19 Release Note for TruCluster Patch 95.00
When the last member is rolled and right after the version switch is thrown, a script will run which will put CAA on hold and copy the old datastore to the new datastore. CAA will connect to the new datastore when it is available.
The time required to do this depends on the amount of information in the datastore and the speed of each member machine. For 50 resources we have found the datastore conversion itself to only take a few seconds.
To undo this patch, the following command must be run:
/usr/sbin/cluster/caa_rollDatastore backward
You are prompted to guide the backward conversion process.
One step of this command will prompt you to kill the
caad
daemons on all members.
A
caad
daemon may still appear
to be running as an uninterruptible sleeping process (state
U
in the
ps
command) after issuing a
kill -9
command.
You can safely ignore this and continue with the conversion process
as prompted, because
caad
will be killed when the process
wakes up.
1.20 Release Note for TruCluster Patch 202.00
This section contains release notes for TruCluster Patch 202.00.
1.20.1 Enablers for EVM
This patch provides enablers for the Compaq
SANworksTM
Enterprise Volume Manager (EVM) Version 2.0.
1.20.2 Rolling Upgrade Version Switch
This patch uses the rolling upgrade version switch to ensure that all members of the cluster have installed the patch before it is enabled.
Prior to throwing the version switch, you can remove this patch by returning
to the rolling upgrade install stage, rerunning
dupatch,
and selecting the Patch Deletion item in the Main Menu.
You can remove this patch after the version switch is thrown, but this requires a shutdown of the entire cluster.
To remove this patch after the version switch is thrown, use the following procedure:
Note
Use this procedure only under the following conditions:
The rolling upgrade that installed this patch, including the clean stage, has completed.
The version switch has been thrown (
clu_upgrade -switch).A new rolling upgrade is not in progress.
All cluster members are up and in multiuser mode.
Run the
/usr/sbin/evm_versw_undo
command.
When this command completes, it asks whether it should shut down the entire cluster now. The patch removal process is not complete until after the cluster has been shut down and restarted.
If you do not shut down the cluster at this time, you will not be able to shut down and reboot an individual member until the entire cluster has been shut down.
After cluster shutdown, boot the cluster to multiuser mode.
Rerun the rolling upgrade procedure from the beginning (starting
with the setup stage).
When you rerun
dupatch, select the
Patch Deletion item in the Main Menu.
For more information about rolling upgrades and removing patches, see
the
Patch Kit Installation Instructions.
1.20.3 Restrictions Removed
The restriction of not supporting multiple filesets from the
cluster_root
domain has been removed.
It is now fully supported
to have multiple filesets from the
cluster_root
domain
to be mounted in a cluster; however, this could slow down the failover of
this domain in certain cases and should only be used when necessary.
The restriction of not supporting muliptle filesets from a boot partition domain has been removed. It is now fully supported to have multiple filesets from a node's boot partition to be mounted in a cluster; however, when the CFS server node leaves the cluster all filesets mounted from that node's boot partition domain will be force unmounted.