DTrace

I've finally got some spare time to download a PEAR module for DTrace. What a great module! I've found a little problem with it, wrote a letter to Wez Furlong, and he immediately changed the source code to make it work even better. Thanks a lot, Wez! :)

So, here it is - my first PHP Dtrace script: php-scripts-snoop.d



So go ahead, download the script, do chmod a+x for it, and after you start it in a terminal of your web-server, you can run PHP scripts from this server, and our DTrace script will be reporting us whenever each PHP script stars or finishes, specifying which Apache process is responsible for this:



pS: yes, starting of today I've decided to provide download links for each of my scripts - should be more convenient for you now. This means that sooner or later I'll update all the archive blog entries to have download links for respective scripts.

When you're writing a DTrace script, often you'd like to pass some parameter in command line. Such an easy task might be really hard unless you read a docs.sun.com section about DTrace scripting, particularly a section about comman line parameters macros.

As with sh or bash, you can access command line parameters via $0..$9 macroses. But there's a catch. Values of these macroses should match a certain definition - a number, an identifier or a string. If there isn't a match here, you'll get an error.

Let's start with a simple script.



If you pass a number as a command line parameter, there will be no error, and you'll get this message:
Your parameter: 123

But if you pass a string instead of number, here's the error you'll get:

bash-3.00# ./args.d a1b2c3
dtrace: failed to compile script ./args.d: line 9: failed to resolve a1b2c3: Unknown variable name

This happens because DTrace tries to find an identifier "a1b2c3". Why does this happen? Because of the way DTrace tries to recognize the type of a command line parameter. The parameter doesn't look like a number, but to make DTrace accept the value as a string, you have to specify it in quotes. Without them, DTrace accepts we've passed an identifier name. And since there isn't one with such a name, we get an error.

To prove this theory, you simply have to create a variable with the same name in your script:


There you go - it works just like I said:

Your parameter: 1979

And if your parameter is definitely a string, you have to change your script (the line with printf, so that it has %s for a string, and not %d for an integer, otherwise you'll get another error)...


... and also put your parameter in quotes, like this:

bash-3.00# ./args.d '"a1b2c3"'
Your parameter: a1b2c3

As you can see, we're getting a string we passed, and not the variable with the same name, which was left in the script intentionally to demonstrate it's not used anymore.

And finally, one more thing. If you want all your command line parameters to be treated as strings by default and even leave the quotes around parameters out, all you have to do is to access the macroses for your parameters with a double $ sign, and then the parameter type definition will be skipped:



And here's how you'd access such a script with the same parameter we've used before:

bash-3.00# ./args.d a1b2c3
Your parameter: a1b2c3

That's it for today! Good luck with your DTrace scripts!

Yesterday Bryan Cantrill (one of DTrace authors) provided a link to the presentation he along with two other DTrace authors gave recently on advanced DTrace scripting. There are lots of useful tips, tricks and gotchas explained, which might be useful for both newbies and some seasoned DTrace users.

As it's states one the very first slides of the presentation, some of the things presented are quite simple - most of the tips you'd know if you read the documentation carefully, but the tips given are very useful. I've learned lots of new things, so I strongly recommend anyone interested in DTrace to find some time and read it as well. Here is the presentation in a PDF file.

Quite ofter we'd like to know what happens to a particular process on a system, and if we're using DTrace for our investigation, we'd probably use the $target variable (I've already spoked about it in the past) or simply specify the process identifier (pid) in some predicates of our probes, thus pointing to DTrace that we're after only a certain process. $target variable still can and should be used when creating our probes with pid provider.


For DTrace beginners it's quite a common and good practice. But there is a better way: using the pid provider.

As it's explained in the official DTrace guide, pid provider isn't just a provider, but in fact is a whole class of providers. And, as the name suggests, it provides us with probes related to a certain process.

For instance, pid737 provider allows us to trace everything happening within a process with pid of 737. What's really cool about this provide - it's not only easier to scope our interest, but it also gets much easier to see how where certain probes originate from (what libraries provide certain functions used by our process, read on - I'll explain it a bit later).

Such a way of looking at a certain process, in contrast to using predicates like /pid == $target/, is more correct. Instead of enabling all the specified probes by default, and then using predicates for each probe firing for each process on the system only to see whether we're interested in a given process, DTrace won't even look at other processes - and pid737 will make sure that all the probes specified will be enabled and possibly fired only for the specified process.

We already know how to get the list of all the probes known to DTrace. I've explained it a while ago. The thing you need to remember about the pid provider is this: after you've used pid provider in some probes for a process, dtrace -l will start reporting you these probes at the end of all the available probes. They've been dynamically allocated just for you. If the process in question dies or finishes, all the dynamically allocated probes for its pid provider will disappear.

One more thing I really like about pid provider - modules used in probes are in fact libraries used for the execution of the process you're looking at. This gives you a wonderful opportunity of observing only what's been done in your process by functions of a particular library. Very useful.

Right, enough of theory - here's an example. First, we create a simple bit of "Hello, world!" code in C:



After you compile it, let's get going with out DTrace script:



Save the script, make it executable, and start it, specifying our hello as a command to start:



You see this list of probes? I won't give you the full list - it's going to be almost a 1000 lines, but I hope you get the idea. It's also a perfect opportunity to see how easy it's going to be for you to track probes of a particular library.

Back to our example, it's obvious what I'm going to do now: I'd like to get our printf caught with a probe.



If we start tihs script, here's what you'll get:

At last, OpenSolaris.Org is up!

As it was expected, it's not possible to download OS sources just yet. Instead, to prove that the whole OpenSolaris idea is serious, Sun revealed DTrace sources.

Bryan Cantrill has posted a very interesting entry in his blog today, I strongly recommend you read it: Solaris 10 Revealed.