Alarms, Errors, and Troubleshooting
555-233-143
4-10
Issue 1 May 2002
Troubleshooting a Duplicated Server
The sections,
‘‘Initialization and Recovery’’ on page 3-1
, and
‘‘IPSV-CTL (Ipserver Interface Control)’’ on page
, contain procedures for troubleshooting specific problems with servers and
IPSIs.
!
CAUTION:
Follow normal escalation procedures before shutting down either an
application or the entire system. Then, execute the shutdown only when
advised by the appropriate tier’s Services representative.
!
CAUTION:
MultiVantage application resets can have wide-ranging disruptive effects.
Unless you are familiar with resetting the system, follow normal escalation
procedures before attempting a demand reset.
If a spontaneous server interchange has occurred, assume that a serious fault
has occurred on the current standby server. The following symptoms indicate that
a spontaneous server interchange has taken place:
■
A SYSTEM error is logged in the Error log.
■
An interchange entry is recorded in the initcauses log.
The occurrence of a recent interchange is displayed in the Bash shell’s server
screen.
There are two possible causes of a spontaneous interchange:
■
Major hardware failure
■
Failed recovery that has been software-escalated
If the interchange was fault-driven, there are two ways of finding the cause.
■
Using alarm and error logs in conjunction with the timestamp described
below.
After a spontaneous server interchange has occurred, the alarm log retains
a record of any MAJOR ON-BOARD alarm against a server component
that took place before the interchange. This record is retained for 3 hours
and may indicate the cause of the interchange when testing is not possible
or conclusive. Other information in the error log may also be helpful.
■
Testing the standby server when the logs do not identify the problem.
Start by determining the time of the interchange. (From the server’s Bash shell
prompt, enter server, and refer to the
Elapsed Time Since Last Spont.
Interchange
field
.)
Then, examine the alarm and error logs as described in
the following section. If this does not identify the problem, proceed to the next
section, which describes a sequence of tests of the standby server.
Summary of Contents for S8700 Series
Page 50: ...Maintenance Architecture 555 233 143 1 26 Issue 1 May 2002 ...
Page 74: ...Initialization and Recovery 555 233 143 3 12 Issue 1 May 2002 ...
Page 186: ...Alarms Errors and Troubleshooting 555 233 143 4 112 Issue 1 May 2002 ...
Page 232: ...Additional Maintenance Procedures 555 233 143 5 46 Issue 1 May 2002 ...
Page 635: ...status psa Issue 1 May 2002 7 379 555 233 143 status psa See status tti on page 7 406 ...
Page 722: ...Maintenance Commands 555 233 143 7 466 Issue 1 May 2002 ...