|
51
by bouchardl
|
1 |
crashdc : an automated collection tool |
2 |
======================================
|
|
3 |
||
|
89
by louis_bouchard
|
4 |
crashdc is an automated collection tool . It is intended to be run whenever |
5 |
a new vmcore file is generated in order to collect basic crash dump data for |
|
6 |
offline analysis. It can also be executed interactively on existing dump files. |
|
|
51
by bouchardl
|
7 |
|
8 |
0. Preliminary warning |
|
9 |
======================
|
|
|
89
by louis_bouchard
|
10 |
This is the beta release of crashdc. Please report any issue you find or |
11 |
comments you may have. We definitively want to hear from any |
|
12 |
issue/comment/rant/praise you would like to submit. If you want to, you can |
|
13 |
submit these at crashdc-devel@lists.sourceforge.net |
|
|
51
by bouchardl
|
14 |
|
15 |
1. Introduction |
|
16 |
===============
|
|
|
89
by louis_bouchard
|
17 |
Crash dump files (i.e. vmcore) are becoming larger and larger. It is not |
18 |
uncommon to encounter files larger than 16 Gb. It is becoming difficult to have |
|
19 |
those files transfered to vendor's facilities for analysis. And sometimes, only |
|
20 |
a few standard crash commands are necessary to have a good idea of what caused |
|
21 |
the crash. |
|
22 |
||
23 |
crashdc is meant to run automatically after creation of the vmcore file. It will |
|
24 |
gather the main crash data elements an transfer them into a text file. Normally, |
|
25 |
this is only done on the most recent vmcore generated. |
|
26 |
||
27 |
But when invoked manually using the init.d script with the 'generate' keyword, |
|
28 |
it is possible to generate specific reports, using specific modes supplied on |
|
29 |
the command line. |
|
|
51
by bouchardl
|
30 |
|
|
95
by louis_bouchard
Updated version including split of INSTALL |
31 |
2. crashdc operation |
32 |
====================
|
|
33 |
Crashdc main usage is to automate the collection of basic data elements presents |
|
34 |
in a vmcore file. Automation of its execution can be done using on of these two |
|
35 |
methods : |
|
36 |
||
37 |
* kdump post-save trigger |
|
38 |
* init script |
|
39 |
||
40 |
While the kdump method is better integrated in the dump procedure, it can appear |
|
41 |
as limitative, especially since it runs within the kexec reserved space. For |
|
42 |
instance, it may be necessary to reserve up to 256 Mb of kexec space (SLES11) in |
|
43 |
order for crashdc to run properly. This might prove to be impossible on some |
|
44 |
system with limited amount of memory. |
|
45 |
||
46 |
If this happens, then the init script method will prove to be a better choice as |
|
47 |
it happens during the normal course of a reboot, late in the boot process and |
|
48 |
doesn't require an increase in kexec memory reservation. It may also be the only |
|
49 |
possible method on environments where kexec/kdump is not available at all (i.e. |
|
50 |
RHEL4). |
|
51 |
||
52 |
But automatic execution of crashdc is not required. It is possible to use the |
|
53 |
init script manually to create crash-data-{date}.txt reports. It is also |
|
54 |
possible to use this method to override the default mode (as defined in |
|
55 |
/etc/sysconfig/crashdc) or to provide custom-made crash commands through a file. |
|
56 |
||
57 |
Finally, the crashdc tool itself can be used as a command line tool, in |
|
58 |
situations where the debuginfo RPM cannot be installed, specific kernel |
|
59 |
locations are used or non standard environments are a necessity. |
|
60 |
||
61 |
For further details on each one of the commands refer to : |
|
62 |
||
63 |
* crashdc(8) : The crashdc command |
|
64 |
* crashdc(7) : The init script |
|
65 |
* crashdc(5) : The configuration file |
|
66 |
||
67 |
3. crashdc testing context |
|
|
51
by bouchardl
|
68 |
==========================
|
|
89
by louis_bouchard
|
69 |
crashdc is currently tested in a limited environment which consist of standard |
70 |
installs of RHEL5, SLES10 and SLES11 in VM. No specific configuration is done |
|
71 |
except for what is described here. |
|
|
97
by louis_bouchard
test scripts for SLES10 |
72 |
|
73 |
4. crashdc known limitation |
|
74 |
===========================
|
|
|
101
by louis_bouchard
Added known limitation section |
75 |
|
76 |
4.1 Local storage only |
|
77 |
----------------------
|
|
|
97
by louis_bouchard
test scripts for SLES10 |
78 |
So far, crashdc has been tested on local storage only. This means that it might |
79 |
not work at all using NFS network storage (or CIFS on SLES). It will not work at |
|
80 |
all with ftp/scp as the vmcore file is sent away to another host. If you want to |
|
81 |
use crashdc in this fashion, you will have to install it on the remote server |
|
82 |
where the vmcore file is stored and will not be able to use the automated |
|
83 |
method. |
|
84 |
||
85 |
You still can use the manual method to generate the crash-data-{date}.txt file. |
|
|
101
by louis_bouchard
Added known limitation section |
86 |
|
87 |
4.2 Same kernel type |
|
88 |
--------------------
|
|
89 |
When the /etc/init.d/crashdc script is invoked manually to generate the |
|
90 |
crash-data-{date}.txt file, it supposes that the booted kernel is the same than |
|
91 |
the one that generated the vmcore file. If both are different, an error will be |
|
92 |
displayed and the command will fail. |