-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, A while ago, I posted to this list information about crashdc, a tool that I develop which make use of the crash utility to extract a text file out of a vmcore automatically. It is now available in beta for public consumption here : http://sourceforge.net/projects/crashdc/files/ All functionalities have been tested on RHEL5, SLES10 and SLES11 for the x86 and x86_64 architectures. For a brief outline of the project, here is a copy of the included README file. More details can be found on the project page. Kind Regards, ...Louis > 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@xxxxxxxxxxxxxxxxxxxxx > > 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. - -- Louis Bouchard, Linux Support Engineer Team lead, EMEA Linux Competency Center, Linux Ambassador, HP HP Services 1 Ave du Canada HP France Z.A. de Courtaboeuf louis.bouchard@xxxxxx 91 947 Les Ulis http://www.hp.com/go/linux France http://www.hp.com/fr -----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----- -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
