This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Missing appname in lket output
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. How about it?
BTW, any special condition that a user has to turn off fork/execve?
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).
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:
1> add the event name into each row of record, so it will look like:
10.24319 APPNAME: sshd PID:7203 CPU:3 EVENT_NAME:syscall.return
HOOKGRP:2 HOOKID:2 syscall:write,
73.232758 APPNAME: mime.browse PID:19697 CPU:0
EVENT_NAME:iosysall.write.entry HOOKGRP:9 HOOKID:7
fd:9,buff_addr:-1208643584,count:3773,
but it will make the final ascii output a little larger. But it
seems that we can delete "HOOKGRP:9 HOOKID:7" if we provided the
EVENT_NAME
2> write the event description data into a separate file, e.g,
lket.meta, which looks like:
2 1 syscall.entry
2 2 syscall.return
9 7 iosyscall.write.entry
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.