…and so do I; after having a 20 minute introduction to it c/o Darren Moffat midweek, I am positively enthused about DTrace.
The Register article [www.theregister.co.uk] suffers from having to explain DTrace to ordinary people; for Unix geeks it is probably fastest to say:
It’s the bastard offspring of an unholy three-way union between your favourite symbolic debugger, and KADB, and AWK; and it’s totally cool.
There seem to be some good examples at [users.tpg.com.au] linked from [www.sun.com]
I’ve seen stuff like a five-line shellscript which will dump every write() that any process performs – of length greater than 100 bytes with a full stack traceback if desired.
Or neutering processes: intercept each time that a process called “ssh” attempts to perform connect(); trap the system call and poke it so that it returns -1/ECONNREFUSED.
One thing I can’t find yet is a comprehensive published DTrace cookbook – a directory of dinky scripts that simultaneously do useful things and also demonstrate basic functions. When I find one, I’ll let you know.
Skimming the guide, this is a very basic example extract from [docs.sun.com]
Example 3-1 rtime.d: Compute Time Spent in read(2)
syscall::read:entry { self->t = timestamp; } syscall::read:return /self->t != 0/ { printf(“%d/%d spent %d nsecs in read(2)\n”, pid, tid, timestamp – self->t); /* * We’re done with this thread-local variable; * assign zero to it to allow the DTrace runtime * to reclaim the underlying storage. */ self->t = 0; }
and it continues…
If you find a process that’s of particular interest, add a predicate to learn more about its read(2) behavior: syscall::read:entry /execname == “Xsun”/ { self->t = timestamp; }
Leave a Reply