Making procfs Cooler© Amit Singh. All Rights Reserved. Written in May 2007
I earlier wrote and released as open source a MacFUSE-based process file system (procfs) for Mac OS X. This document describes some new features I added to procfs soon after its first release. The source code for all features discussed here is available.
Processes that have "names" (from the standpoint of the Process Manager in Mac OS X) now can be looked up more conveniently. There is a new subdirectory called
byname/, which shows named processes as symbolic links to the respective
$ ls -F /proc/
0/ 14577/ 193/ 202/ 223/ 33/ 40/ 51/ 706/
1/ 152/ 195/ 207/ 228/ 34/ 41/ 54/ 707/
130/ 156/ 198/ 210/ 23/ 35/ 42/ 59/ 89/
135/ 161/ 199/ 213/ 27/ 36/ 45/ 61/ byname/
13928/ 165/ 200/ 216/ 291/ 38/ 46/ 62/ system/
14293/ 187/ 201/ 219/ 32/ 39/ 47/ 67/
$ ls -F /proc/byname
Adium@ Microsoft AU Daemon@ iTunes Helper@
AirPort Disk Agent@ Safari@ loginwindow@
Dock@ SystemUIServer@ procfs@
Google Notifier@ UniversalAccessApp@
$ ls -l /proc/byname/Terminal
lrwxr-xr-x 1 root wheel 0 Jun 4 15:22 /proc/byname/Terminal -> ../202
You can now see information in procfs files about the windows (if any) of a given process. A new subdirectory
/proc/<pid>/windows/ contains files with such information. For example, you can see the size and screen coordinates of each window of a process in the
onscreen file within this directory.
$ cat /proc/byname/Terminal/windows/onscreen
1 3a 32 x 22 @ (893, 0, 25)
2 44 503 x 364 @ (0, 388, 0)
3 42 503 x 364 @ (-1, 22, 0)
4 118 503 x 364 @ (505, 22, 0)
5 45 503 x 364 @ (503, 389, 0)
6 43 503 x 364 @ (504, 22, 0)
Open File Descriptor Information (x86-Only Feature)
A new file
/proc/<pid>/fds now contains information on the file descriptors that are open in the process. For file descriptors that refer to "actual" files, you will see the full pathname to the corresponding file for each descriptor. For descriptors that are TCP sockets, you will see the local and remote address/port information. The output shown below has been trimmed for width.
$ cat /proc/byname/Safari/fds
0 vnode /dev/null
1 vnode /dev/console
2 vnode /dev/console
5 POSIX shm
6 vnode /dev/urandom
7 vnode /System/Library/.../A/Resources/Extras2.rsrc
8 vnode /Users/singh/Library/Syndication/Database3
9 socket SOCK_STREAM, tcp, AF_INET, 10.0.0.1:4312 --> 188.8.131.52:20480
10 socket SOCK_DGRAM, ip, AF_UNIX
11 socket SOCK_DGRAM, ip, AF_UNIX
12 vnode /dev/random
13 socket SOCK_STREAM, tcp, AF_INET, 10.0.0.1:4568 --> 184.108.40.206:47873
16 vnode /System/Library/.../A/Resources/HIToolbox.rsrc
18 vnode /System/Library/.../English.lproj/Localized.rsrc
23 socket SOCK_DGRAM, ip, AF_UNIX
37 vnode /Library/Internet Plug-Ins/.../Flash Player.rsrc
38 vnode /Library/Internet Plug-Ins/.../Flash Player.rsrc
42 vnode /System/Library/.../A/Resources/QuickTime.rsrc
43 vnode /System/Library/.../English.lproj/Localized.rsrc
There is a new subdirectory called
system/ that contains further subdirectories such as
$ ls -F /proc/system
/proc/system/firmware/variables contains a view of the system's firmware variables.
$ cat /proc/system/firmware/variables
<string>-v debug=0x14e kdp_match_name=bogus</string>
hardware/ subdirectory contains some new subdirectories in addition to those that were present in the previous version of procfs.
$ ls -F /proc/system/hardware
camera/ displays/ motionsensor/
cpus/ lightsensor/ mouse/
/proc/system/hardware/displays/ directory contains a subdirectory for each connected display that is online. For example, if you have two displays, you will see subdirectories
/proc/system/hardware/displays/. The subdirectory for a specific display contains an
info file and a
$ ls -F /proc/system/hardware/displays
$ ls -F /proc/system/hardware/displays/0
$ cat /proc/system/hardware/displays/0/info
base address 0x2018000
bits per pixel 32
bits per sample 8
samples per pixel 3
bytes per row 5888
main display yes
builtin display yes
OpenGL acceleration yes
model number 00009c57
serial number 00000000
unit number 00000000
vendor number 00000610
There are numerous other pieces of information in a running system that you could export through procfs. There's a reason as to why I added files to export the particular information discussed so far: the code to retrieve most of such information was cut-and-pasted from the code I wrote for Mac OS X Internals.
An "Always-Live" Screenshot File
screenshot.tiff file is especially interesting. The idea is this: the file contains, in TIFF format, a rendering of what's on that display—it's an always-live screenshot! You can simply copy this file to get a screenshot of that display. You copy it again, and you get a new screenshot, and so on. You can even double click on the file within the Finder and the screenshot image will open up "normally".
By default, a procfs volume is marked as "nobrowse" for the Finder. This means that by itself, the Finder will not go into such a volume. procfs does this for technical reasons that we won't go into here. However, for looking at such screenshots, you can instruct the Finder to go into the procfs volume through the
Go —> Go to Folder... menu item or the
shift-cmd-G key combination.
Picture 1. The
screenshot.tiff file in a display subdirectory contains a "live" screenshot of that display
An "Always-Live" Camera File
Along the same lines as an "always-live" display screenshot, we can have a
screenshot.tiff file for a camera such as the built-in iSight on many Apple computer models. The
/proc/system/hardware/camera/screenshot.tiff file serves that purpose. Every time you open this file, the camera will be briefly activated, a picture will be taken, the camera will be deactivated, and the picture data would be made to look like a TIFF file by procfs. Thus, every time you open this file, you get a new picture—basically what the camera is seeing at that point in time. You could copy the file at some intervals to do some sort of surveillance.
Activating and deactivating the camera has some latency. procfs shoots a picture only when the
screenshot.tiff file is opened and it isn't already open. The picture so taken will persist until you close the file (that is, procfs will not shoot a new picture until you close the file). Some applications, such as
Preview.app, may access the file in a manner that increases the amount of time the camera is activated as compared to, say, the case when you simply copy the file instead of opening it in place.
Picture 2. The
screenshot.tiff file in the
camera contains a "live" picture (what the camera is seeing)
Thanks to Dan Waylonis, Dave MacLachlan, and Tim Omernick for their help with image processing and sequence grabbing.
The source for procfs can be accessed on the MacFUSE project web site.
You can download a precompiled procfs binary here.