[dtrace-discuss] Use pid provider probes for a varying number of processes

[Chip Bennett]

Well that's pretty cool, and actually lends itself to a fairly elegant 
solution (IMHO).

Knowing that you are going to "probe" a process later, you could create 
the pid provider probes at the time you fork the process, with a dtrace 
command that just exits, something like:

    sleep 1000 &
    dtrace -q -n "BEGIN { exit(0) }" -n "pid$!:sleep:main:return {}"

Later, another DTrace program can specify something like 
pid*:sleep:main:return and match all of the previously created 
background jobs.  You still have to pre-load all of the functions you 
want to trace, but it would make the final D program much simpler.

Chip


Adam Leventhal wrote:
> On Fri, Dec 01, 2006 at 10:26:49AM -0600, Chip Bennett wrote:
>   
>> It's my understanding that the actual provider name for the pid provider 
>> (pidnnnn) is static, and is variable before D compilation proper, when 
>> macros are still being evaluated (i.e. pid$1).  So you could pass a long 
>> list of PIDs to your D program.
>>     
>
> That's not quite right. The pid provider probes are created on the fly by
> libdtrace, but matching happens in the kernel as normal. By default there
> are no pid provider probes:
>
> # dtrace -n pid*:::
> dtrace: invalid probe specifier pid*:::: probe description pid*::: does not match any probes
>
> But if I were to make some with other DTrace enablings:
>
> # dtrace -n pid170011::main:entry
> dtrace: description 'pid170011::main:entry' matched 1 probe
> ^C
> # dtrace -n pid170017::main:return
> dtrace: description 'pid170017::main:return' matched 1 probe
> ^C
>
> The original probe description will match those probes:
>
> # dtrace -n pid*:::
> dtrace: description 'pid*:::' matched 2 probes
> ^C
> # dtrace -n pid*::: -l
>    ID   PROVIDER            MODULE                          FUNCTION NAME
>   455  pid170011              tcsh                              main entry
>   456  pid170017              bash                              main return
>
> We only create probes on demand when an explicit pid is provided; the
> thinking is that actually sifting through every process isn't ever what
> you really want, and it wouldn't pick up newly spawned processes.
>
> One solution might be if we supported following traced processes on fork.
> This is something we've wanted to do for some time, but it's a significant
> project.
>
> Adam
>
>