DTrace is returning the execname of the PID 0 process, which is "sched". This will happen if the CPU is running at an elevated priority level (PIL 11 or greater, if memory serves), and the dtrace probe is an anchored probe (i.e. the probe is associated with a module and function), as per the source code here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/dtrace/dtrace.c#2838 (line 2845). This happens pretty often when looking to correlate disk IO or network IO with a process name, because IO's are asynchronous in nature. That is, the calling thread issues a blocking system call (read, write, etc), and the IO moves down the code path into the kernel, and the calling thread is put to sleep and enqueued on a sleep queue. In my experience, it's not uncommon to have dtrace report "sched" as the execname when instrumenting the IO code path (disk or network). When I'm looking to correlate IO activity with processes, I usually use the syscall provider, where you will always get the actual name of the calling process (if a process is generating IO, disk or network, they're issuing system calls). When chasing network IO, you can use a predicate with the syscall provider to capture processes reading/writing sockets: syscall::read:entry, syscall::write:entry / fds[arg0].fi_fs == "sockfs" / { @e[execname] = count(); } HTH, /jim Andras Barna wrote: > -bash-3.2# dtrace -qn 'ip:ip:*:receive{ printf("from: %s exec: %s\n", > args[2]->ip_saddr,execname ); }' > from: 207.46.110.14 exec: sched > ^C > -bash-3.2# dtrace -qn 'ip:ip:*:send{ printf("to: %s exec: %s\n", > args[2]->ip_daddr,execname ); }' > to: 207.46.110.14 exec: pidgin > ^C > > why sched is displayed? > > _______________________________________________ dtrace-discuss mailing list [email protected]
