It's the ID of the probe, not the provider.
/jim
Andrea Cucciarre' wrote:
I guess that the ID you see it's the ID of the provider not the PID
On 07/10/09 16:01, Robert Alatalo wrote:
Hello,
Trying to track down what application is causing the system to
reboot by turning the uadmin system call's reboot into a panic, we
are running the following script:
-x-x- start of uadmin.d -x-x-
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::uadmin:entry
/arg0 == 1 && uid == 0/
{
panic();
}
syscall::uadmin:entry
{
trace("I am not root")
}
-x-x- end of uadmin.d -x-x-
We are getting a string of output:
dtrace: script '/usr/local/bin/uadmin.d' matched 2 probes
dtrace: allowing destructive actions
CPU ID FUNCTION:NAME
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
261 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
259 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
...
...
I thought that the ID should be a PID, but
# ps -ef|grep 8063
<<dores not find it>>
Any suggestions on how to track down this rouge entity which is
futilely trying to do something with uadmin?
thanks,
Robert
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
