This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new feature and discussion: filtering on pids


On 9/6/05, Martin Hunt <hunt@redhat.com> wrote:
> I've checked in some new options that allow systemtap to focus on a
> specific pid. Dtrace does the same with the "-c" option and $target
> macro. I'd like to propose some further changes, but first here is what
> I checked in:
> 
> Say you have a very simple script:
> 
> probe kernel.function("sys_open") {
>         log (execname()." opens ".user_string($filename))
> }
> 
> You want to use this to see what files xemacs is opening. So you start
> your script, run xemacs, stop xemacs, then stop the script. And
> somewhere in the middle is the output you want.  With the "-c" option
> you can do that much simpler.
> 
> > stap -c "xemacs foo.c" opens.stp
> 
> And now the script starts and ends with the command you started, "xemacs
> foo.c".  However, you still have some opens in your output that were
> from other processes on your system.  To filter them out, modify
> opens.stp like this:
> 
> probe kernel.function("sys_open") {
>         if (target() == pid())
>                 log (execname()." opens ".user_string($filename))
> }
> 
how do you deal with a multithread app that doesn't use CLONE_PID?
wouldn't the test fail since each thread has a seperate pid?

James Dickens


> Now you will get every sys_open() call made by the xemacs process you
> started and nothing else.
> 
> There is a new related stap option, "-x pid".  It causes target() to
> return whichever pid you pass in.
> 
> > stap -x 1234 opens_pid.stp
> would return every file process 1234 opens. (Note that if process 1234
> exits, systemtap currently won't exit.  You will have to ^C it like
> normal.)
> 
> While doing this, I got to thinking that it would be nice if I didn't
> have to modify my scripts to check the current pid against target()
> everywhere.  Why not make this automatic? It would be easy enough to
> have the translator put some code at the very beginning of each probe to
> check if a target pid was set and if so don't execute the probe unless
> it matched the current pid. In fact I tried it and it works very nicely.
> ANY script can be made to apply only to a specific process simply by
> using the "-c" or "-x" options. No changes to the script are required.
> 
> Then I thought about tracking child processes and client-server
> interaction and I realized that this wouldn't cover those.  Do we need
> to extend this feature to include filtering on a list of processes?
> Should automatic filtering on pid be enabled by a separate flag? Or
> should there be alternate options (like "-C" and "-X") that work like
> "-c" and "-x" but enable the automatic filtering?
> 
> Martin
> 
> 
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]