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?
>
>