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 12-11-2009, 10:29 PM
James Washer
 
Default calling crash from another program (or vice versa)

Often, I'd like to be able to run one crash command, massage the data
produced, and run follow up commands using the massaged data

A (possibly crazy) example, run the mount command, collect the
superblocks addresses, for each super_block, get the s_inodes list head,
traverse each list head to the inode, for each inode, find it's i_data
(address_space) and get the number of pages.. Now.. sum these up and
print a table of filesystem mounts points and the number of cached pages
for each... Perhaps, I'd even traverse the struct pages to provide a
count of clean and dirty pages for each file system.

I do do this by hand. (i.e. mount > mount.file; perlscript mount.file >
crash-script-step-1, then, back in crash I do ". crash-script-step-1 >
data-file-2; and repeat with more massaging).. This is gross, prone to
error, and not terribly fast.

I'd love to start crash as a child of perl and either use expect (which
is a bit of a hack) or better yet, have some machine interface to crash
(ala gdbmi)...

I know.. it's open source, I should write it myself. I just don't want
to reinvent the wheel, if someone else already has done something like
this.

Perhaps I need to learn sial. But what little sial I've looked at seems
a bit low level for my needs.

Has anyone had much luck using expect with crash?

thanks

- jim


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 12-12-2009, 10:02 AM
Adrien Kunysz
 
Default calling crash from another program (or vice versa)

James Washer wrote:

Often, I'd like to be able to run one crash command, massage the data
produced, and run follow up commands using the massaged data


From the example you give I think a SIAL or Python script
<http://sourceforge.net/projects/pykdump/> is what

you want. As for using Perl I guess you are welcome to write
the appropriate module


Has anyone had much luck using expect with crash?


We use Expect internally for some very simple things that could
probably be done with "crash -i". It works fine but for anything
not trivial it becomes a bit too hacky I think.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 12-14-2009, 12:40 PM
"Chouinard, Luc"
 
Default calling crash from another program (or vice versa)

Jim -

Indraneel Mukherjee (mukherjee.indraneel@gmail.com) posted these to the
lkcd mailing list some time ago. You might want to look at some of those
- there's one about mounts and one about SBs.

Sial does not provide reentrancy back to crash. On the plus side, you
can pretty much cut&paste kernel code straight into you script, so you
don't have to be a kernel guru to get the info you want. A good source
of code is the /proc hooks that are employed throughout kernel and
driver code...


-Luc


> -----Original Message-----
> From: crash-utility-bounces@redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of James Washer
> Sent: Friday, December 11, 2009 6:29 PM
> To: Discussion "list for crash utility usage,maintenance and
> development
> Subject: [Crash-utility] calling crash from another program
> (or vice versa)
>
> Often, I'd like to be able to run one crash command, massage
> the data produced, and run follow up commands using the massaged data
>
> A (possibly crazy) example, run the mount command, collect
> the superblocks addresses, for each super_block, get the
> s_inodes list head, traverse each list head to the inode, for
> each inode, find it's i_data
> (address_space) and get the number of pages.. Now.. sum these
> up and print a table of filesystem mounts points and the
> number of cached pages for each... Perhaps, I'd even traverse
> the struct pages to provide a count of clean and dirty pages
> for each file system.
>
> I do do this by hand. (i.e. mount > mount.file; perlscript
> mount.file > crash-script-step-1, then, back in crash I do ".
> crash-script-step-1 > data-file-2; and repeat with more
> massaging).. This is gross, prone to error, and not terribly fast.
>
> I'd love to start crash as a child of perl and either use
> expect (which is a bit of a hack) or better yet, have some
> machine interface to crash (ala gdbmi)...
>
> I know.. it's open source, I should write it myself. I just
> don't want to reinvent the wheel, if someone else already has
> done something like this.
>
> Perhaps I need to learn sial. But what little sial I've
> looked at seems a bit low level for my needs.
>
> Has anyone had much luck using expect with crash?
>
> thanks
>
> - jim
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>


Confidentiality Notice: This e-mail (including any attachments) is intended only for the recipients named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please notify the sender of that fact and delete the e-mail from your system.

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 12-14-2009, 03:21 PM
James Washer
 
Default calling crash from another program (or vice versa)

Thanks all.. I take a look at the various options recommended.
On Mon, 2009-12-14 at 08:40 -0500, Chouinard, Luc wrote:
> Jim -
>
> Indraneel Mukherjee (mukherjee.indraneel@gmail.com) posted these to the
> lkcd mailing list some time ago. You might want to look at some of those
> - there's one about mounts and one about SBs.
>
> Sial does not provide reentrancy back to crash. On the plus side, you
> can pretty much cut&paste kernel code straight into you script, so you
> don't have to be a kernel guru to get the info you want. A good source
> of code is the /proc hooks that are employed throughout kernel and
> driver code...
>
>
> -Luc
>
>
> > -----Original Message-----
> > From: crash-utility-bounces@redhat.com
> > [mailto:crash-utility-bounces@redhat.com] On Behalf Of James Washer
> > Sent: Friday, December 11, 2009 6:29 PM
> > To: Discussion "list for crash utility usage,maintenance and
> > development
> > Subject: [Crash-utility] calling crash from another program
> > (or vice versa)
> >
> > Often, I'd like to be able to run one crash command, massage
> > the data produced, and run follow up commands using the massaged data
> >
> > A (possibly crazy) example, run the mount command, collect
> > the superblocks addresses, for each super_block, get the
> > s_inodes list head, traverse each list head to the inode, for
> > each inode, find it's i_data
> > (address_space) and get the number of pages.. Now.. sum these
> > up and print a table of filesystem mounts points and the
> > number of cached pages for each... Perhaps, I'd even traverse
> > the struct pages to provide a count of clean and dirty pages
> > for each file system.
> >
> > I do do this by hand. (i.e. mount > mount.file; perlscript
> > mount.file > crash-script-step-1, then, back in crash I do ".
> > crash-script-step-1 > data-file-2; and repeat with more
> > massaging).. This is gross, prone to error, and not terribly fast.
> >
> > I'd love to start crash as a child of perl and either use
> > expect (which is a bit of a hack) or better yet, have some
> > machine interface to crash (ala gdbmi)...
> >
> > I know.. it's open source, I should write it myself. I just
> > don't want to reinvent the wheel, if someone else already has
> > done something like this.
> >
> > Perhaps I need to learn sial. But what little sial I've
> > looked at seems a bit low level for my needs.
> >
> > Has anyone had much luck using expect with crash?
> >
> > thanks
> >
> > - jim
> >
> >
> > --
> > Crash-utility mailing list
> > Crash-utility@redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> >
> >
>
>
> Confidentiality Notice: This e-mail (including any attachments) is intended only for the recipients named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please notify the sender of that fact and delete the e-mail from your system.
>
> email message attachment
> > -------- Forwarded Message --------
> > From: Luc Chouinard <lucchouina@yahoo.com>
> > To: Chouinard, Luc <Luc.Chouinard@trueposition.com>
> > Subject: Fw: [lkcd-devel] Some additional SIAL scripts for lkcdutils
> > Date: Thu, 24 Sep 2009 07:35:20 -0500
> >
> >
> > ----- Forwarded Message ----
> > From: Indraneel Mukherjee <mukherjee.indraneel@gmail.com>
> > To: lkcd-devel@lists.sourceforge.net
> > Sent: Thursday, September 24, 2009 7:32:12 AM
> > Subject: [lkcd-devel] Some additional SIAL scripts for lkcdutils
> >
> > Hi,
> > We wrote some additional SIAL scripts for lkcdutils.
> >
> > Details:
> > ---------
> >
> > 1. files.sial - Similar to the 'sfiles' command listing info on open files for processes in the dump.
> > 2. inodeinfo.sial - Prints detailed info for the given inode number of a given superblock in the dump.
> > 3. lsmount.sial - List the mounted file systems in the dump.
> > 4. meminfo.sial - Similar to /proc/meminfo.
> > 5. mutexinfo - Shows the owner and waiting processes for a given mutex address.
> > 6. psched.sial - Similar to /proc/$PID/sched
> > 7. superblkinfo.sial - Lists all the fs superblocks and the associated inodes.
> >
> > They've been tested on lcrash dumps for linux-2.6.22 through 26 for ARM architecture.
> >
> > Can these be added to the lkcdutils svn repo?
> >
> > Warm Regards,
> > Indro
> >
> > plain text document attachment (ATT1316106.txt), "ATT1316106.txt"
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 09:33 AM.

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