>> >> On 16 Apr 2008, at 23:32, Roman Shaposhnik wrote: >> >>> On Mon, 2008-04-14 at 23:03 +0100, Bayard Bell wrote: >>>> I've just recently started working with DTrace and one of the first >>>> issues I've run across is the difficulty in following child >>>> processes >>>> when instrumenting user space. >>> >>> Are trying to survive fork/exec or just a single process forking its >>> image? >> >> I'm looking to re-initialise the same set of probes under the pid >> provider against child processes subsequently created by fork/exec.
> Well, if you're really talking about re-inserting probes into a > completely new image (after the exec) > than I consider DTrace to be doing exactly the right thing -- these > are brand new probes so they have to be reinserted. I am dealing with same problem as Bayard trying to trace child processes. >From Roman's answer I do not exactly know if it is possible or not. What do >you mean with "....DTrace to be doing exactly the right thing -- these are brand new probes so they have to be reinserted....."?? I've tried to trace my test program which spawns child and I really wasn't able to see any trace output for that child from pid provider. >From my point of view as the name of probe "pidPID" has to be specified statically I can see no way how to trace child processes (as we don't know PID when starting the script) without destructive hacks like ones described in this thread http://mail.opensolaris.org/pipermail/dtrace-discuss/2007-April/003733.html. I consider the way how pid provider works a big drawback of dtrace for user-land debugging/tracing. I often need to debug complex multi-process application/service where I just can't do something like "dtrace -c app". Cosider a daemon - after start, daemons often spawns new process, daemonize child with setsid etc. and letting parent process die. Yes I can look for PID after that and run new dtrace session but then I will lose lot of interesting information (like deamon initialization). Other good examples are short-lived processes spawned by master process - you really do need to know what's happening inside them. I would like to see something like shortlived.d script from DTraceToolkit but with capability to trace function calls not only time spent in them. Other thing that would be possible if there wouldn't be a need to specify PID statically within pid provider would be nice library tracing. Wouldn't be nice if following would be possible?: :mylibrary.so:myfunction:entry { printf("myfunction: parameter x %d was supplied by program %s with PID %d\n",arg[0],execname,pid); } With this I could as questions like: What programs are using this library function? What program uses this library function most frequently? What is the common pattern that this function is receiving? However I really do not know if it is technically possible to create "dynamic pid provider" :-) J. _______________________________________________ dtrace-discuss mailing list [email protected]
