FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

LinkBack Thread Tools
Old 03-22-2010, 07:04 AM
Louis Bouchard
Default crashdc is now available in beta

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 :


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,


> 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@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.

- --
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@hp.com 91 947 Les Ulis
http://www.hp.com/go/linux France
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkunJHoACgkQDvqokHrhnCzeQwCfUaGsjlkrX6 nbQn0pfjcgVUf0

Crash-utility mailing list

Thread Tools

All times are GMT. The time now is 03:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org