Re: Missing appname in lket output

[Li Guanglei <guanglei at cn dot ibm dot com>]

Li Guanglei wrote:
> David Boreham wrote:
> > <slaps forehead>
> > I did wonder about that but I figured 'no, it couldn't be that simple'.
> > But surely we need this documented, otherwise anyone using LKET will
> > have the same question ? I'd be happy to update the man page if that'd
> > help.
> >
> > > I ever thought of turning on fork/execve events by default, but 
> > > finally I left it to the users to decide whether they want to capture 
> > > such events. Do you think we should turn on fork/execve capture by 
> > > default since they have a negligible overhead?
> >
> > Well I did assume that those probes were added by default, since I could
> > see tht they were required by b2a. I would say yes, with perhaps a flag
> > to disable them for situations where enabling them would not be 
> > appropriate.
>
> It seems that it will be more convenient if lket turns on tracing 
> process fork/execve events by default. But there is no way to turn off 
> an already turned-on probe. The trouble is that if user script turns on 
> process fork/execve again, then LKET will be trigger twice every time 
> fork or execve is called.
>
> So my suggestion is that we document clearly that fork/execve have 
> already be turned on by default, and we change the probe alias of 
> addevent.process.fork/addevent.process.execve to something like 
> lketinternal.process.fork/lketinternal.process.execve so that a probe 
> point like "addevent.*" in user stp script won't trigger fork/execve 
> once again. 


I checked in some changes. I made fork/execve trace hooks lket 
internally and turned them on by default. But stoptrace_fork and 
stoptrace_exec flags are provided for lket to control	stopping 
fork/execve in user scripts. For example:

probe begin
{
  stoptrace_fork = 1
  stoptrace_exec = 1
}
probe addevent.iosyscall, addevent.scsi {}

And I also change the probe name of fork/exec to 
lket_internal.process.fork/lket_internal.process.execve to avoid 
duplicated probe points if user use "probe addevent.* {}"
	
> > > I don't remember that LKET ever wrote event names into lket.out. Only 
> > > group id and hook id is written. Can you paste here a snippet of the 
> > > output?
> >
> > Sure, I'm reading the man page here :
> > http://sourceware.org/systemtap/man5/lket-b2a.1.html
> > (cvs has the same version). I see output like this:
> >
> > 10.24319 APPNAME: sshd PID:7203 CPU:3 HOOKGRP:2 HOOKID:2 syscall:write,
> >
> >
> > that appears to show the event name : "syscall:write". But when I run 
> > b2a I get output like this:
> > 73.232758 APPNAME: mime.browse PID:19697 CPU:0 HOOKGRP:9 HOOKID:7 
> > fd:9,buff_addr:-1208643584,count:3773,
> >
> > After a few hours working with these files I do know that 9,7 is 
> > 'write' but wouldn't it be
> > handy to emit the event name in the file ? (actually there's not much 
> > need IMHO for the
> > group and hook ids because they're not human-readable anyway).

Agree.

> >
>
> Yes. syscall:write is only the output while not the event name. I also 
> think that "9,7" is hard to read. So there are two options:
> [...]

I checked in some changes for lket-b2a. Now three additional options 
are provided to control the output of lket.out, by default lket.out 
will contain appname, event name, but won't contain groupid and 
hookid. You can use -a, -n, -i option to control whether or not to 
output these three data fields.

> > > Couple of reasons for postprocessing in MySQL:
> >
> > Yeah I don't disagree, I'm just reporting my user experience.
> > Actually I'm supposedly a database expert , but I mainly work
> > with their internal implementation rather than actually _using_ them ;)
> >
> > > This example will generate top 10 most frequently syscalls
> >
> > Examples would be good. I can probably generate some.
> > The first thing I need to do is make a script that invokes
> > mysql in an automated fashion, avoiding all that show databases; use 
> > xxxxx; stuff.
> > It should just pick the most recent one.
>
> It will be great if you can add your store procedures/scripts into LKET. 
> People will find lket easier to use if we provides as much as more the 
> store procedures/shell scripts for post-processing.
I also updated the man page and SystemTap website for these changes. 
Thanks for your comments and suggestions.

- Guanglei