[Crash-utility] crashdc is now available in beta

crashdc : an automated collection tool ====================================== crashdc is an automated collection tool . It is intended to be run whenever a new vmcore file is generated in order to collect basic crash dump data for offline analysis. It can also be executed interactively on existing dump files. 0. Preliminary warning ====================== This is the beta release of crashdc. Please report any issue you find or comments you may have. We definitively want to hear from any issue/comment/rant/praise you would like to submit. If you want to, you can submit these at crashdc-devel(a)lists.sourceforge.net 1. Introduction =============== Crash dump files (i.e. vmcore) are becoming larger and larger. It is not uncommon to encounter files larger than 16 Gb. It is becoming difficult to have those files transfered to vendor's facilities for analysis. And sometimes, only a few standard crash commands are necessary to have a good idea of what caused the crash. crashdc is meant to run automatically after creation of the vmcore file. It will gather the main crash data elements an transfer them into a text file. Normally, this is only done on the most recent vmcore generated. But when invoked manually using the init.d script with the 'generate' keyword, it is possible to generate specific reports, using specific modes supplied on the command line. 2. crashdc operation ==================== Crashdc main usage is to automate the collection of basic data elements presents in a vmcore file. Automation of its execution can be done using on of these two methods : * kdump post-save trigger * init script While the kdump method is better integrated in the dump procedure, it can appear as limitative, especially since it runs within the kexec reserved space. For instance, it may be necessary to reserve up to 256 Mb of kexec space (SLES11) in order for crashdc to run properly. This might prove to be impossible on some system with limited amount of memory. If this happens, then the init script method will prove to be a better choice as it happens during the normal course of a reboot, late in the boot process and doesn't require an increase in kexec memory reservation. It may also be the only possible method on environments where kexec/kdump is not available at all (i.e. RHEL4). But automatic execution of crashdc is not required. It is possible to use the init script manually to create crash-data-{date}.txt reports. It is also possible to use this method to override the default mode (as defined in /etc/sysconfig/crashdc) or to provide custom-made crash commands through a file. Finally, the crashdc tool itself can be used as a command line tool, in situations where the debuginfo RPM cannot be installed, specific kernel locations are used or non standard environments are a necessity. For further details on each one of the commands refer to : * crashdc(8) : The crashdc command * crashdc(7) : The init script * crashdc(5) : The configuration file 3. crashdc testing context ========================== crashdc is currently tested in a limited environment which consist of standard installs of RHEL5, SLES10 and SLES11 in VM. No specific configuration is done except for what is described here. 4. crashdc known limitation =========================== 4.1 Local storage only ---------------------- So far, crashdc has been tested on local storage only. This means that it might not work at all using NFS network storage (or CIFS on SLES). It will not work at all with ftp/scp as the vmcore file is sent away to another host. If you want to use crashdc in this fashion, you will have to install it on the remote server where the vmcore file is stored and will not be able to use the automated method. You still can use the manual method to generate the crash-data-{date}.txt file. 4.2 Same kernel type -------------------- When the /etc/init.d/crashdc script is invoked manually to generate the crash-data-{date}.txt file, it supposes that the booted kernel is the same than the one that generated the vmcore file. If both are different, an error will be displayed and the command will fail.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkunJHoACgkQDvqokHrhnCzeQwCfUaGsjlkrX6nbQn0pfjcgVUf0 1eUAnAsFHUUxq5IAyubtDbivdtA6/Vug =7k4M -----END PGP SIGNATURE-----