Apologies up front I'm new to Dtrace and am a Oracle DBA by trade so D is a bit new to me....
I have a problem in which I need to find all command with args executed following a failure of a network interface in the grid infrastructure. I downloaded Brendan Gregg's DTrace toolkit and this was just the ticket, so I managed to get all the commands being executed using execsnoop.
However the action printf("%s\n", curpsinfo->pr_psargs); is truncated to 80 chars and I need > 80 chars. I read that this could be achieved using stop, pargs and start, but have no idea how to put this together (tho am gonna try!).
Was hoping someone had done this already and was willing to help.
Thanks in advance.
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?
Thanks for the feedback, I'll try increasing the switch rate like you said. There's no tutorial I'm following that is recommending the shell script wrapper, I was just shamelessly using Brendan Gregg's scripts as a base for my own.... :-)