Have you ever wanted to find out a bit more detail about what exactly your system is doing at a given point in time? Perhaps your hard drive is thrashing about, or a program is crashing at the same spot each time you run it, or you’d like to see exactly which files get modified when you change a given program’s settings. Although there are no foolproof methods of figuring this stuff out, one of the tools you can put to use is a Unix utility called fs_usage. Today’s hint will show you the basics of using it, and give some examples of how it might help you figure out what’s going on with your machine.
fs_usage is a real-time tool (i.e. it runs and creates output as things happen) that reports activity related to the file system. When launched, it will immediately start filling your Terminal screen with output, even if you’re not doing anything other than just sitting there watching it. You must run fs_usage as root, as it uses a system-level tool to work. Here’s an example of just a few seconds of its output. As you can see, there’s a ton of data that goes flying by, and too quickly to read. You aren’t necessarily concerned with what you see in real time, though. As a brief overview, let’s just look at one line of the output:
08:25:15 getattrlist /Applications/iChat.app/Contents/MacOS/iChat 0.000044 MicrosoftMouse
The first column (08:25:15) is the time of the entry; the second (getattrlist) is the actual file system command being executed (more on that in a bit), the third column is the file involved (if applicable; often this column is blank), the next column (0.000044) is the time required for execution, and the last column (MicrosoftMouse) is the name of the process that generated the activity. Of all of these, the two most interesting columns are the one for the file involved and the name of the calling process. It’s those two values that may enable you to figure out what’s happening on your system. You can get more detail on fs_usage by reading its manual by typing man fs_usage in the Terminal.
As for the name of the actual command being executed (getattrlist in this case), for the most part you don’t need to understand what each command is (though many are fairly obvious, such as read, write, etc.). However, if you’re curious, you can look each of them up on Apple’s API Reference: Man Pages. Use your browser’s search function to find the link to the command you’d like to read about (they should all be in the area of the page labeled Section 2. As an example, here’s the entry for getarrlist.
So, how do you use all this seemingly arcane knowledge to help with a problem or question regarding an application? Here’s how I put it to use…
- Open Terminal and type sudo fs_usage -w > ~/Desktop/usage.txt. The first part of the command launches the fs_usage utility with the “wide output” (-w) option enabled—this insures that you see all of its output (it otherwise truncates columns to fit the Terminal’s window width). The > sign redirects the output from fs_usage into a filename that you specify. In this case, that’s a file named fsusage.txt on your user’s desktop. By redirecting the output to a file, you don’t need to work through the output in the Terminal later on.
- Do whatever it is that you’d like to investigate—launch the app that crashes, use your machine until you hear the disk churn that you’ve been trying to identify, modify the settings in a given program, etc.
- After you’ve seen the behavior you were looking for, switch back to the Terminal and hit Control-C to terminate fs_usage.
- Switch to your Desktop, and using your favorite text editor, open the file usage.txt. This will potentially be a large file, given how much information fs_usage captures. If you’re looking for something related to a particular application, use your editor’s search feature to search for that program’s name. If you’re trying find the source of a lot of disk activity, look for a whole bunch of read and write commands, and then check the last column to see which process is creating them. If you’re trying to find a file that’s modified when you set a program’s preferences, search on both the program’s name and maybe “.plist” to find any plist files that were updated. The process isn’t black and white; you’re doing detective work based on a peek at your system as it was actually running, so what you’ll see will depend on what you were doing.
As a good real-world example of putting fs_usage to work, check out this hint, describing how someone used it (and remote access via ssh) to identify and fix the cause of a crash that was preventing the user from logging in.
As I mentioned when I started this blog a couple weeks back, Friday’s entries will tend to be the “geekiest” of the week, as you can clearly see by today’s hint. This is not something you’ll use regularly, of course. But it can be quite useful in certain situations, and sometimes it’s just kind of interesting to take a peek behind the covers and see what you’re machine’s up to, even when you think it’s just sitting there waiting for you to do something.