NameDateSize

..29-Aug-20174 KiB

.gitignore29-Aug-201721

apicmds/29-Aug-20174 KiB

autoltp29-Aug-20173.7 KiB

create_dmesg_entries_for_each_test.awk29-Aug-20171.1 KiB

create_kernel_faults_in_loops_and_probability.awk29-Aug-20171.3 KiB

create_valgrind_check.awk29-Aug-20171.4 KiB

genhtml.pl29-Aug-201712.5 KiB

genload/29-Aug-20174 KiB

html_report_header.txt29-Aug-20172.7 KiB

insert_kernel_faults.sh29-Aug-20172.7 KiB

ltp_check29-Aug-20178.7 KiB

ltp_master29-Aug-20173.8 KiB

ltpoutput29-Aug-20171.3 KiB

ltpoutput229-Aug-20171.3 KiB

ltprun29-Aug-20173.5 KiB

make-file.sh29-Aug-20171.4 KiB

Makefile29-Aug-20171.2 KiB

netpipe-2.4/29-Aug-20174 KiB

netpipe-2.4-ipv6/29-Aug-20174 KiB

pounder21/29-Aug-20174 KiB

rand_lines.c29-Aug-201714.1 KiB

README29-Aug-20174.1 KiB

restore_kernel_faults_default.sh29-Aug-20175 KiB

STPfailure_report.pl29-Aug-20174.2 KiB

strace_test/29-Aug-20174 KiB

top-LTP/29-Aug-20174 KiB

README

1LTP Automation
2~~~~~~~~~~~~~~~
3
4The LTP automation scripts are intended to completely automate the
5updating, running, and reporting of an LTP test run. The ltpupdate script
6simply produces a copy of the latest CVS code and packages it up as a tgz
7file and uploads it to the designated LTP host machine. The ltp_master
8script first kicks off the test (this could possibly be controlled by another
9script say after a new release for example). This script uploads the
10ltprun script (which does the actual test run) to each machine specified.
11Currently I use this mostly as a single shot run. I envision a time to come
12when I have enough machines to run a copy of LTP against a test farm of say
13the same distro on different machine configurations, or on every machine I
14have control over for example. The ltprun scripts does what one would
15usually do on a system to be tested, download the code, compile, execute,
16but it also handles the reporting process as well. It will upload the data
17to the LTP host to be collected later. The ltp_check script does the brunt
18of the results processing. It produces a results.out file which has a
19summary of the system under test, the success (or failure) of the test and
20if there are failures the output from each testcase.
21
22Here's the scenario (pardon the ASCII art);
23
24----------  ------            -----------
25|master|    |test|            |ltp_host|
26----------  ------            -----------
27  |             |                     |
28  +-------------+---------------------+
29
30
31I've divided it up into 3 machine types viz, "master", "test" and
32"ltp_host". For purposes of this documents lts consider we have one test
33machine.
34
35ltp_master script
36~~~~~~~~~~~~~~~~~
37The ltp_master script is the driver that runs LTP testsuite on a machine
38of choice, it takes a single argument ie the name of the victim machine
39
40ltp_master can be invoked in the following 3 ways:
41
42#1 ltp_master -f system_file
43 - system_file is an ASCII file containing the list of victim machines.
44
45#2 ltp_master system.name.dom.com
46 - space separated names of victim machines.
47
48#3 ltp_master
49 - will prompt user for the names of the victim machines.
50
51I reccomend using scheme #2, this will help seperate different
52distros, platforms etc, for example, We might say have a file with RedHat
53machines, or all SuSE, or all machines of a certain platform (say zSeries).
54
55Regardless of how it's invoked ltp_master does the following on each
56victim machine.
57
58  -  FTP connect to the test system and uploads ltprun
59  -  Telnet to each system and kick off ltprun ( runs under nohup )
60
61ltprun script
62~~~~~~~~~~~~~
63ltprun is where bulk of the automation of ltp is done.
64It does the following.
65  - downloads the ltp test suite tarfile (ltp.tgz) from ltp_host.
66  - uncompress the test suite and compile it.
67  - runs the test suite.
68  - tars up the results.
69  - uploads results back to ltp_host.
70
71In case any of the get, build, run fails, the script will still upload
72the results back to the ltp_host machine, so you don't have to try to remember
73which runs were kicked off and correlate that with which runs were reported.
74
75ltp_check
76~~~~~~~~~
77ltp_check lives on the master machine, this script has to be run as root
78user and it saves the ltp test results in /root/ltp_results.
79
80ltp_check does the following;
81  - FTPs to ltp_host and downloads all of the *-ltpoutput.tgz files
82  - Creates a results directory for each machine (using the short
83    hostname) and for each run (based on timestamping)
84  - Uncompresses the gathered result files into the new directory
85  - parses results gathered,  saves it as results.out file in the same
86    directory. The results are sorted by system name and then run time.
87
88Note:
89  - Check through the scripts for appropriate variables that you may need to
90change in order to customize further, they should be at the beginning of the
91file.
92
93  - This "fire and forget" might not work 100%. But if you find a test
94(like pth_str02) that hangs you can log in as root and do something like;
95killall pth_str02 a few times and the test should pick up where it left
96off.
97
98Please send comments or suggestions to:
99
100Jay Huie
101wjhuie@us.ibm.com
102Linux System Test
103Phone: 845-435-8164
104