Hidden Gems In Leopard: OpenSnoop


I have a confession to make: I have not always been a Mac person. For the period of time between the retirement of System 9 and Panther (yes, it took Apple showing a real commitment to Unix for me to give them a shot again), I abandoned our fine operating system for greener pastures, well, green screen at least. Work drove me into Windows (as it has for about 90% of the workers out there) but my real outlet was anything Linux, BSD or Solaris-related. There was nary a distro that did not cross my hard drive (virtual or otherwise) and I was very happy programming, scripting and living life on the command line, with an occasional, lingering trip into X11 when necessary.

OS X changed all that, since Apple managed to make Unix look very good while keeping all of the real power that lies beneath the GUI.Now, one may be able to argue the aesthetics of  Leopard (hey, Panic should be happy, it took Leopard to finally drive me into purchasing CandyBar), but none can dispute the gems that await those who dare to invoke the Terminal, and I’ll be taking the opportunity over some of the coming posts to dwell on the nuggets that bear a deeper look. For those that are not as comfortable with the more textual side of their systems, I’ll be making these trips as painless as possible (you may not need to delve into the Utilities folder to find the Terminal icon at all).

The first stop is a little utility called opensnoop. Leopard ships with something called DTrace that gives developers and administrators the ability to take a peek at what all running code is doing in a flexible and dynamic way. Giving DTrace the coverage it deserves is beyond a simple blog post, but there are some smaller utilities – like opensnoop – that take advantage of the power of DTrace, but on a more targeted scale which are worthy of a minor exposition.The main purpose of the opensnoop utility is to provide a report of file opens as they occur. Curious as to what really happens when Safari opens a web page? Want to see what files are accessed from that latest program you downloaded? You can find the answers with opensnoop.

If you can get to a terminal prompt, the simplest way to see what this utility does is to just type:

sudo opensnoop 

Non-Terminal folks can just run the OpenSnoop.app application from the OpenSnoop App Archive (354KB ZIP file). (Either way, you’ll be asked to enter your password since opensnoop requires higher-level privileges to run.)

Output will look something like the following, though your listing contents should be very different:

UID    PID COMM            FD PATH 
501    286 SystemUIServer  17 /System/Library/CoreServices/Menu Extras/Spaces.menu/Contents/Resources/SpacesBackground.pdf
501    218 Finder          11 /.vol/234881026/571978
501    286 SystemUIServer  17 /System/Library/CoreServices/Menu Extras/Spaces.menu/Contents/Resources/SpacesBackground.pdf
501    286 SystemUIServer  17 /System/Library/CoreServices/Menu Extras/Spaces.menu/Contents/Resources/SpacesBackground.pdf
0      110 WindowServer     4 /var/log/windowserver.log 
0      110 WindowServer     4 /var/log/windowserver.log 
501    286 SystemUIServer  17 /System/Library/CoreServices/Menu Extras/Spaces.menu/Contents/Resources/SpacesBackground.pdf

For each line:

  • UID is the numerical ID of the owner of program that has the file opened.
  • PID is the process ID of the program that has the file open
  • COMM is the actual name of the process (this is something we care about)
  • FD is the numerical file descriptor (ID) of the file being accessed
  • PATH is the full OS X path to the file being accessed (this is also something we care about)

The sample output is what occurred when I switched to/from Spaces 1 & 3. Just that simple case shows how interesting opensnoop can be since we see that the SystemUIServer and WindowServer were both invoked when I worked just a little bit with Spaces and that SpacesBackground.pdf was loaded from one of the Spaces app bundles.

While this is useful in-and-of itself, we can use opensnoop for more targeted and detailed inspection. The following command:

sudo opensnoop -avgn Safari

(Non-Terminal users can run the SnoopSafari.app from the archive)

Produces the following output when I tell it to go to google.com:

TIME           STRTIME                UID    PID  FD ERR PATH                 ARGS
8071248908     2008 Jan 10 21:33:13   501   1153  17   0 /Users/bob/Library/Caches/com.apple.Safari/Cache.db-journal Safari



Don’t forget about rwsnoop and iosnoop! rwsnoop is all file read and write activity (not just opening of files), and iosnoop is system I/O, i.e. only stuff that finally hits the disk.

And even better you can modify at least rwsnoop and iosnoop to give final summary statistics for the data run. Here are rwsnoop and iosnoop modified for summary stats:


Note as they are just scripts, you can diff them and see what changes have been made.

Billy Halsey

@BoB — Thanks for the info on opensnoop! I’m a long-time Unix geek myself (and it was my intention on joining the TAB staff to do the series that you’re doing now, but it didn’t happen…), but as I’m sure you’re aware, there are always ‘Nix tools you never knew existed, forgot about, or just plain don’t tend to use. If you’re interested in teaming up on this series, get in touch with me.

BoB Rudis

For those that do install the Developer tools, Instruments (/Developer/Applications/Instruments.app) gives you a powerful way to peek into any app.

You can also find some more opensnoop-ish DTrace “one-liners” by opening up a Terminal session and entering “man -k dtrace”.

BoB Rudis

You do not need to recompile applications. The DTrace facility is “always there” and you tell it what to focus on.

Patrick Weigel

That looks cool.

So snoop relies on DTrace? Does DTrace require the applications it looks at to be set up in a special way? For example, was Safari compiled to be DTrace aware?

Comments are closed.