XSCF Log Information

A P P E N D I X B

This appendix explains the following XSCF log information that can be referenced using the XSCF Shell showlogs(8) command on the XSCF console.

The log types that can be referenced by the showlogs(8) command are shown below. See TABLE 8-3 for an outline of each log, its size, and generation number.

XSCF Error Log

Power Log

Event Log

Monitor Message Log

Temperature and Humidity History Log

Console Log

Panic Log

IPL Log

The logs that can be referenced by the showaudit(8), showad(8), and showldapssl(8) commands are shown below.

Audit Log

Active Directory Log

LDAP/SSL Log

B.1 XSCF Error Log

To reference the log related to a status notification or a fault information that occurred in the server, use these two commands:

showlogs(8) error option

fmdump(8)

The showlogs(8) error option displays fault information in a format specific to the platform. Conversely, the fmdump command displays fault information in a format compatible with the Oracle Solaris OS. This latter command is provided for users who are familiar with the Oracle Solaris OS. When the log is referenced by these two commands, there is a difference in display format but little difference in the information. Use these commands in the following cases:

To check whether a fault occurred if a message is output to the domain console and XSCF console. (See Appendix A.)

To check whether the information is fault information if it was reported to the previously registered email address.

To check whether the information is fault information if TRAP occurred in the SNMP manager.

Using the `showlogs`(8) Command to Confirm a Fault

1. Specify the error option on the XSCF Shell and perform the showlogs(8) command to reference the XSCF error log.

XSCF> showlogs error 
Date: Mar 30 15:45:31 JST 2005      Code: 00112233-44556677-8899aabbcceeff00
	Status: Warning                    Occurred: Mar 30 15:45:26.000 JST 2005
	FRU: PSU#1,PSU#2
	Msg: ACFAIL occurred (ACS=3)(FEP type = A1)
Date: Mar 30 17:45:31 JST 2005      Code: 00112233-44556677-8899aabbcceeff00
	Status: Alarm                      Occurred: Mar 30 15:45:26.000 JST 2005
	FRU: PSU#1,PSU#2,*
	Msg: ACFAIL occurred (ACS=3)(FEP type = A1)

(The layout of the command example is subject to change without previous notice for functional improvement.)

In the example above, the following items are displayed:

Time at which each problem was logged (Date). This date is indicated in local time.

DIAGCODE that the field engineer and authorized service personnel use for troubleshooting (Code). The user is requested to inform the field engineer and authorized service personnel of this Code. This is useful in settling the problem at an early stage.

Fault level of the component (Status). One of the following items is displayed:

Alarm:	The relevant component failed.
Warning:	Some subcomponents in the relevant component failed or degraded.
Information:	Notification.
Notice:	System state notification.

Time at which each problem occurred (Occurred). This is indicated in local time.

Replacement component (FRU) that is probably faulty. A comma (,) separates two suspect components displayed. For additional suspect components, an "*" (asterisk) is displayed after the comma (,). Each component is displayed hierarchically in a component mounting path format. Whether more suspect components are to be displayed depends on the position where the fault was detected.

The following explains cases where "FRU :" is displayed.

(a) "PSU#1, PSU#2" is displayed.

The above indicates the following: PSU#1 and PSU#2 were detected as the first and second suspect components, respectively. It might be necessary to replace the respective components as circumstances require.

(b) "PSU#1, PSU#2,*" is displayed.

The above indicates the following: PSU#1 and PSU#2 were detected as the first and second suspect components, respectively, with other components also detected. It might be necessary to replace the respective components.

The above indicates the following: IOU#0/PCI#3 was detected as the suspect component, and PCI slot No.3 of I/O unit No.0 is problematic. It might be necessary to replace the device connected to PCI slot No.3 as circumstances require.

(d) "MBU_A/MEMB#0/(MEM#02A)" is displayed.

The above indicates the following: MBU_A/MEMB#0/MEM#02A was detected as the suspect component, and memory slot No.02A of memory board No.0 on the MBU is problematic. It may be necessary to replace memory slot No.02A as circumstances require.

(e) "CMU#0/MEM#02A" is displayed.

The above indicates the following: CMU#0/MEM#02A was detected as the suspect component, and memory slot No.02A of CMU 0 is problematic. It may be necessary to replace memory slot No.02A as circumstances require.

(f) "CMU#0/MEM#02A-02B" is displayed.

The above indicates the following: CMU#0/MEM#02A-02B was detected as the suspect component, and memory slot No.02A and No.02B of CMU 0 are problematic. It may be necessary to replace the memory as pairs in memory slots No.02A and No.02B as circumstances require.

One-row message to indicate an outline of the problem (Msg).

Message ID that can be used to access the corresponding description of information at the specified URL site (MSG-ID). (The -v option must be specified.)

For the message ID, the following information can be confirmed at the web site.

Message type (Type)

Fault level (Severity)

Outline of fault (Description)

Machine operation after the fault (Automated response)

Influence (Impact)

Action to be taken (Action)

Detailed information (Details)

3. Repair the fault according to the recommended processing.

For details of the showlogs(8) command, see the XSCF Reference Manual or the man page.Use the fmdump(8) command to confirm the XSCF error log in a display format that is compatible with the Oracle Solaris OS.

Using the `fmdump`(8) Command to Confirm a Fault

1. Perform the fmdump(8) command on the XSCF Shell and reference the log.

XSCF> fmdump 
TIME                  UUID                                  MSG-ID
Dec 28 13:01:27.3919  bf36f0ea-9e47-42b5-fc6f-c0d979c4c8f4  FMD-8000-11
Dec 28 13:01:49.3765  3a186292-3402-40ff-b5ae-810601be337d  FMD-8000-11
Dec 28 13:02:59.4448  58107381-1985-48a4-b56f-91d8a617ad83  FMD-8000-OW
:

(The layout of the command example is subject to change without previous notice for functional improvement.)

In the example above, the following items are displayed:

Time at which the problem was registered in the log (TIME).

Universal Unique Identifier that can be used to uniquely identify the problem in an optional system set (UUID)

Message ID (MSG-ID) that can be used to access the corresponding description of information at the specified site

2. Use the message ID for accessing the specified URL to acquire detailed information corresponding to this problem. For the specified URL, see the web site information about the messages described in the Product Notes for your server. The information that can be referenced for the message ID is the same as that described in the item of showlogs(8) error.

3. After confirming the problem, repair the fault according to the recommended processing.

For details of the fmdump(8) command, see the XSCF Reference Manual or the main page.

B.2 Power Log

When a power operation or resetting is performed in the server or domain, the XSCF firmware collects a power log. This section explains how to reference the power log. See TABLE 8-3 for the size and generation number of a power log.

Using the `showlogs`(8) Command to Reference Power Logs

Specify the power option on the XSCF Shell and perform the showlogs(8) command to reference power logs.

<Example 1>  Power logs are displayed as a list.
XSCF> showlogs power
Date                       Event             Cause          DID  Switch
Mar 30 17:25:31 JST 2005   System Power Off  Pow.Fail/Recov.--   Service
Mar 30 17:35:31 JST 2005   System Power On   Pow.Fail/Recov.--   Locked
Mar 30 17:45:31 JST 2005   Domain Power Off  Operator       00   Locked
Mar 30 17:50:31 JST 2005   Domain Power On   Operator       00   Service
 
<Example 2>  Power logs are listed in order of the most-to-least recent by specifying a start time and end time.
XSCF> showlogs power -t Mar3017:302005 -T Mar3017:492005 -r
Date                       Event             Cause          DID  Switch
Mar 30 17:45:31 JST 2005   Domain Power Off  Operator       00   Locked
Mar 30 17:35:31 JST 2005   System Power On   Pow.Fail/Recov.--   Locked

(The examples are subject to change without previous notice for functional improvement.)

In the examples above, the following items are displayed:

Time at which each power log was collected (Date). This is indicated in local time.

Type of power event that occurred (Event). The following lists each event and its meaning:

Event	Meaning
SCF Reset:	The XSCF was reset.
Domain Power ON:	The domain power supply was turned on.
Domain Power OFF:	The domain power supply was turned off.
System Power ON:	The power supply of the server common section was turned on.
System Power OFF:	The power supply of the server common section was turned off.
XIR:	The XIR was reset.
Domain Reset:	The domain was reset.

Factor by which the power event was instructed (Cause). The causes and their meanings are as follows:

Cause	Meaning
Self Reset:	Self-resetting of the XSCF reset the XSCF.
Power On:	Turning on the input power supply reset the XSCF.
System Reset:	The detection of an error reset the XSCF.
Panel:	Operating a switch on the operator panel caused a power event.
Scheduled:	Setting the TOD timer caused a power event.
RCI:	The I/O device connected to the RCI caused a power event.
Pow.Fail/Recov.:	Power recovery turned on the power supply.
Operator:	An operator's instruction caused a power event.
Pow.Fail/Recov.:	A power interruption cut off the power supply.
SW Request:	An Oracle Solaris OS instruction caused a power event.
Alarm:	The server environment or a hardware fault caused a power event.
Fatal:	Fatal caused a power event.
Panic:	Panic caused a power event.

Domain ID for power event (DID)

Mode switch status on the operator panel (Switch). The following lists the switches and their meanings:

Switch status	Meaning
Locked:	The mode switch is locked.
Service:	The mode switch is in service.

B.3 Event Log

When an event occurs in the server, such as when the system status changes, the configuration is changed, the operator panel operated, or an event was sent to the Oracle Solaris OS in the server or domain, the XSCF firmware collects an XSCF event log. The field engineer and authorized service personnel use the XSCF event logs to analyze a fault that occurs, investigate the server operation status, or reference the history of maintenance operation. This section explains how to reference XSCF event logs. See TABLE 8-3 for the size and generation numbers of XSCF event logs.

Using the `showlogs`(8) Command to Reference XSCF Event Logs

Specify the event option on the XSCF Shell and perform the showlogs(8) command to reference XSCF event logs.

<Example>  XSCF event logs are displayed as a list.
XSCF> showlogs event
Date                      Message
Mar 30 17:45:31 JST 2005  System power on 
Mar 30 17:55:31 JST 2005  System power off

(The example is subject to change without previous notice for functional improvement.)

In the example above, the following items are displayed:

Time at which each event log was gathered (Date). This is indicated in local time.

Event message (Message).

B.4 Using the `showlogs` Command to Display Other Logs

This section explains how to reference the other main logs by using showlogs(8) command. For details of each log option of showlogs(8), see the XSCF Reference Manual or the main page. See TABLE 8-3 for the size and generation number of each log.

B.4.1 Monitor Message Log

Using the `showlogs`(8) Command to Reference Monitor Message Logs

An event that occurred in the server is displayed as a monitoring message in real time for the user who logged in the XSCF. The XSCF firmware collects this message in a monitor message log. Specify the monitor option on the XSCF Shell and perform the showlogs(8) command to reference the monitor message log. The following items are displayed:

Time at which the monitoring message was collected (Date). This is indicated in local time.

Monitoring message (Message).

B.4.2 Temperature and Humidity History Log

Using the `showlogs`(8) Command to Reference Temperature and Humidity History Logs

The XSCF firmware collects the environment and temperature and humidity history regarding the server in a temperature and humidity log. The temperature and humidity history log is displayed at ten-minute intervals. Specify the env option on the XSCF Shell and perform the showlogs(8) command to reference temperature and humidity history logs. The following items are displayed:

Time at which each thermal log was collected (Date). This is indicated in local time.

Temperature (Temperature)

Humidity (Humidity). The humidity is only displayed in the M8000/M9000 servers.

Power supply status (ON or OFF) of the server (Power).

B.4.3 Console Log

Using the `showlogs`(8) Command to Reference Console Logs

The XSCF firmware collects the domain console messages output through the XSCF in a console log. A console log is collected as one entry for each line feed code. In some cases, console logs may be called console message logs. Specify the console option on the XSCF Shell and perform the showlogs(8) command to reference console logs. The following items are displayed:

Domain ID (DomainID)

Time at which each console log was collected (Date). This is indicated in local time.

Console message (Message)

B.4.4 Panic Log

Using the `showlogs`(8) Command to Reference Panic Logs

In case of panic, a console message is output to the domain console. This console message is collected by the XSCF firmware in a panic log. In some cases, panic logs may be called panic message logs. Specify the panic option on the XSCF Shell and perform the showlogs(8) command to reference panic logs. The following items are displayed:

Domain ID (DomainID)

Time at which each panic log was collected (Date). This is indicated in local time.

Panic message (Message)

B.4.5 IPL Log

Using the `showlogs`(8) Command to Reference IPL Logs

After the domain power supply is turned on, console messages are output to the domain console until the running status is set. These console messages are collected by the XSCF firmware in an IPL log. In some cases, IPL logs may be called IPL message logs. Specify the ipl option on the XSCF Shell and perform the showlogs(8) command to reference IPL logs. The following items are displayed:

Domain ID (DomainID)

Time at which each IPL log was collected (Date). This is indicated in local time.

IPL message (Message)

B.5 Audit Log

This section explains how to reference the audit logs by using the viewaudit(8) command. For details of each log option, audit class, and audit event of viewaudit(8), see the XSCF Reference Manual or the main page. See TABLE 8-3 for the size and generation number of each log.

Using the `viewaudit`(8) Command to Confirm the Audit Trail

Perform the viewaudit(8) command on the XSCF Shell.

<Example> Display all audit records.
XSCF> viewaudit 
file,1,2006-04-26 21:37:25.626 +00:00,20060426213725.0000000000.SCF-4-0
header,20,1,audit - start,0.0.0.0,2006-04-26 21:37:25.660 +00:00
header,43,1,authenticate,0.0.0.0,2006-04-26 22:01:28.902 +00:00
authentication,failure,,unknown user,telnet 27652 0.0.197.33
header,37,1,login - telnet,0.0.0.0,2006-04-26 22:02:26.459 +00:00
subject,1,opl,normal,telnet 50466 10.18.108.4
header,78,1,command - setprivileges,0.0.0.0,2006-04-26 22:02:43.246 +00:00
subject,1,opl,normal,telnet 50466 10.18.108.4
command,setprivileges,opl,useradm
platform access,granted
return,0

In the example above, By default records are displayed in text format, one token per line, with a comma as the field separator.

The following list displays the Token types and their data (in display order):

File Token

Label, version, time, filename

Header Token

Label, record byte count, version, event type, machine address, time (event recorded)

Subject Token

Label, audit session ID, UID, mode of operation, terminal type, remote IP address, remote port

Upriv Token

Label, success/failure

Udpriv Token

Label, success/failure, privilege name, domain1, ... , domainN

Command Token

Label, command name, argument1, ... , argumentN

Authentication Token

Label, authentication result, user name, message, terminal type, remote IP address, remote port

Return Token

Label, return value

Text Token

Label, text string

Note - Some fields might not be output according to the environment.

The following lists the principal audit events and Tokens:

header

subject

text

return

As for Login telnet.

Logout

Header

Subject

Audit start

Header

Audit stop

Header

Shell command

Header

Subject

Command

Text

Upriv | Updpriv

Return

Note - Some Tokens might not be output according to the environment. Also, it might be changed because of the function improvement without notice.

B.6 Active Directory Log

This section explains how to reference the Active Directory logs by using the showad(8) command. For details of each log option of showad(8), see the XSCF Reference Manual or the main page. See TABLE 8-3 for the size and generation number of each log.

Using the `showad`(8) Command to Confirm the Active Directory Log

Perform the showad(8) command on the XSCF Shell.

When the Active Directory authentication and authorization for users, the diagnostic messages are logged. This log is for use in troubleshooting and is cleared on XSCF reset. Specify the log option on the XSCF Shell and perform the showad(8) command to reference Active Directory logs. The following items are displayed:

Time at which each Active Directory log was collected.

Console message

B.7 LDAP/SSL Log

This section explains how to reference the LDAP/SSL logs by using the showldapssl(8) command. For details of each log option of showldapssl(8), see the XSCF Reference Manual or the main page. See TABLE 8-3 for the size and generation number of each log.

Using the `showldapssl`(8) Command to Confirm the LDAP/SSL Log

Perform the showldapssl(8) command on the XSCF Shell.

When the LDAP/SSL authentication and authorization for users, the diagnostic messages are logged. This log is for use in troubleshooting and is cleared on XSCF reset. Specify the log option on the XSCF Shell and perform the showad(8) command to reference LDAP/SSL logs. The following items are displayed:

Time at which each LDAP/SSL log was collected.

Console message

B.1 XSCF Error Log

Using the showlogs(8) Command to Confirm a Fault

Using the fmdump(8) Command to Confirm a Fault

B.2 Power Log

Using the showlogs(8) Command to Reference Power Logs

B.3 Event Log

Using the showlogs(8) Command to Reference XSCF Event Logs

B.4 Using the showlogs Command to Display Other Logs

B.4.1 Monitor Message Log

Using the showlogs(8) Command to Reference Monitor Message Logs

B.4.2 Temperature and Humidity History Log

Using the showlogs(8) Command to Reference Temperature and Humidity History Logs

B.4.3 Console Log

Using the showlogs(8) Command to Reference Console Logs

B.4.4 Panic Log

Using the showlogs(8) Command to Reference Panic Logs

B.4.5 IPL Log

Using the showlogs(8) Command to Reference IPL Logs

B.5 Audit Log

Using the viewaudit(8) Command to Confirm the Audit Trail

B.6 Active Directory Log

Using the showad(8) Command to Confirm the Active Directory Log

B.7 LDAP/SSL Log

Using the showldapssl(8) Command to Confirm the LDAP/SSL Log

Using the `showlogs`(8) Command to Confirm a Fault

Using the `fmdump`(8) Command to Confirm a Fault

Using the `showlogs`(8) Command to Reference Power Logs

Using the `showlogs`(8) Command to Reference XSCF Event Logs

B.4 Using the `showlogs` Command to Display Other Logs

Using the `showlogs`(8) Command to Reference Monitor Message Logs

Using the `showlogs`(8) Command to Reference Temperature and Humidity History Logs

Using the `showlogs`(8) Command to Reference Console Logs

Using the `showlogs`(8) Command to Reference Panic Logs

Using the `showlogs`(8) Command to Reference IPL Logs

Using the `viewaudit`(8) Command to Confirm the Audit Trail

Using the `showad`(8) Command to Confirm the Active Directory Log

Using the `showldapssl`(8) Command to Confirm the LDAP/SSL Log