Product specifications

5 – Detailed Descriptions of Command LineTools
Advanced Initialization and Verification - ibtest
5-68 D000006-000 Rev A
Q
5.5.4
Interpreting the ibtest log files
Each run of ibtest will create test.log and test.res files in the current
directory.
When ibtest indicates that some or all of the test cases failed, the test.res
and test.log files should be reviewed. test.res will summarize which tests
have failed. Using the test.res file for servers that failed can be quickly
identified. If the problem is not immediately obvious, check the test.log file.
The most recent results will be at the end of the file. The
save_tmp/*/test.log files will be easier to read since they will represent the
logs for a single test case, typically against a single chassis, switch or host.
The keyword FAILURE will be used to mark any failures. Typically due to the roll
up of error messages, the first instance of FAILURE in a given sequence of
failures will show what was being done. Preceeding the FAILURE, the log will
also show the exact sequence of commands issued to the target host and/or
chassis and the resulting output from that host and/or chassis.
For example, test.log may contain lines such as:
scp ./InfiniServPerf.4.1.1.0.15.tgz root@n001a:
TEST CASE FAILURE=scp ./InfiniServPerf.4.1.1.0.15.tgz
root@n001a: failed: ssh: n001a Name or service not known
lost connection
This indicates the scp command shown was executed but failed with the error
message "ssh: n001a Name or service not known.
lost connection"
In this example, this was the exact output from SSH.
If there is a FAILURE message indicating timeout, it means the expected output
did not occur within a reasonable time limit. The time limits used are quite
generous, so such failures often indicate a host, chassis or switch is offline. It
could also indicate unexpected prompts (such as a password prompt when
password-less ssh is expected). Review the test.log first for such prompts. Also
verify that the host can SSH to the the target host or chassis with the expected
password behavior.
Another common source of timeouts is incorrect host shell command prompts.
Verify that both this host and the target host have their prompts set correctly.
The command line prompt must end in # or $ (make certain there is a space
after either).
Yet another common source of timeouts is typograhical errors in selected host
or chassis names. Verify that the host, chassis or switch names in test.log