5 Replies Latest reply on May 18, 2010 2:52 PM by 807559

    Command Line Args > 80 chars

      HI All,

      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.

        • 1. Re: Command Line Args > 80 chars
          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

          syscall::exec:return, syscall::exece:return
          /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.
          • 2. Re: Command Line Args > 80 chars
            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[0]));

            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?
            • 3. Re: Command Line Args > 80 chars
              Oops, I got to typing before I got to thinking, I'm afraid. The proc provider uses the same data structure that curpsinfo does to get to pr_psargs, so it won't help with your character length problem.
              • 4. Re: Command Line Args > 80 chars
                Hi Michael,

                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.... :-)


                • 5. Re: Command Line Args > 80 chars
                  That's not a bad technique to start with, actually. I think I might show more examples myself in that form.