This content has been marked as final. Show 5 replies
wow this D trace stuff f*&%in rocks. Took me longer to write my initial email. Anyway, solved my own problem quickly:
/usr/sbin/dtrace -wn '
#pragma D option quiet
#pragma D option switchrate=10
/uid == 900/
system("pargs %d", pid);
system("prun %d", pid);
it did seem to have an adverse effect on my test system, clearly those destructive actions are not meant for a beginner like me. Ah well I got the info I required.
Would be interested to see more intelligent solutions tho if anybody has any.
Wow. You learn fast. Good work! The following might explain the behavior you suggested wasn't so good.
All system() action results are traced into a DTrace buffer and are executed once the buffer is read -- in the case of your script, ever 1/10 of a second. The information you'd like to get from system() could already be gone by then. So the solution you have forces the thread to stop in order to gather the proc data you want, then resumes. You get the fully monty from pargs(1), but at a cost of delaying the stopped thread up to a tenth of a second while you wait for the buffer to switch and the command to execute.
So if you do this on every exec*() call you have coming through a busy executive process, it could feel a bit muddy, depending on the system. You might try increasing your switchrate, say to 60, for starters. This adjustment will shorten the delay on your system() actions by turning over the buffers faster. That's a quick thing to adjust and test.
Or take a look at the proc provider. Something like:
/ uid == 900 /
printf("Now running %s\n", pid, stringof(args));
BTW, just today I've seen two examples where people are embedding their DTrace programs in shell scripts. I'm curious why? There's nothing wrong with it, of course, but it seems putting a shell wrapper around a DTrace script for its own sake doesn't win very much. Is there a guide or tutorial that recommends this approach?