BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Who Has Which Files
Pages: 1, 2

A "wd" means that this process has a working directory. A working directory is a directory where commands are run from. You could have a command prompt sitting idle in a directory, and that directory would be open by the shell that has that command prompt.

The fourth field has other possible values, but these are by far the most common.

The fifth field gives the mount point where the file resides, and the sixth is the inode of the file. We can use these to find the actual file later.

Then we have the mode of the open file. These appear as standard UNIX filesystem permissions.

The seventh field varies depending on whethere the file in question is a regular file or a device node. If it's a regular file, the seventh field contains the size of the file in blocks. If it's a device node, this field contains the device name.

Finally, we have the read/write status of this file. If the file is open for reading, you'll see an "r." If it's open for writing, you'll see a "w." An "rw", as you might guess, shows that the file is available for reading and writing.

This is pretty powerful, but how can you possibly use it? You cannot sort through 400 lines of output, let alone 30,000 lines. You could filter the output with grep(1), but you may not know exactly what you're looking for. fstat(1) includes three powerful filtering flags. You can use any one of them at a time.

-f filters by mount point. If you're interested in files open in the filesystem where /usr/home/mwlucas lives, you can set that with -f. Note that fstat will not restrict its search to one directory by doing this, but it will automatically figure out which partition that home directory lives on. "fstat -f /usr/home/mwlucas" will give us all the open files on /usr, which is where my home directory is mounted.

-u filters by username. I could run "fstat -u mwlucas" to see all the files I have open. Or I could use the -p flag and specify a process ID to see only files opened by that process.

So let's go back to my original problem. I have a CD-ROM drive that claims to be busy. What's accessing it? My CD-ROM drive is mounted on /cdrom, so I use fstat's -f flag.

# fstat -f /cdrom
chris    tcsh        2834   wd /cdrom   141312 dr-xr-xr-x    6144  r

There is one file open on this disk. That's enough to keep me from unmounting the disk. It's open by user "chris". The interesting thing is the fourth column, with the "wd" entry. This means that the open file is a directory, or a command prompt of some sort sitting on this filesystem. And there is no other activity on the filesystem.

Remember, fstat provides a snapshot of the system's file activity. I can run this command several times in quick succession to see if I just caught Chris at an idle moment. If the disk is accessed, fstat will show other files open. In this particular case, I could also look at the light on the front of the system to see if it's being used at all. But that's far too easy. In any event, the outcome is the same. I pick up the phone, call Chris, and tell him to get his danged idle command prompt out of /cdrom if he's not going to use it.

fstat might have shown extensive work being done on that CD-ROM. If that was the case, Chris' username would have shown up with multiple open files in that directory. I could coordinate with him to get both our jobs done in a timely manner.

If Chris is simply not available--say he's gone home for the night and left his xterm locked--I can just kill his command prompt. He might be annoyed in the morning, but that's OK. Depending on your work environment, you might not want to kill another user's shell. I feel perfectly comfortable killing anything of Chris', so I'll proceed. The third field is the process ID of the shell session somewhere under /cdrom.

# kill -1 2834
# umount /cdrom

I could also forcibly unmount the CD-ROM using umount -f. UNIX provides many different ways to solve this issue. Pick your favorite.

One common annoyance with fstat is that you get the inode of the file being accessed, not the file name. That's not really a problem. You can find file name of the inode with find(1). You can also use the -x argument to find to restrict your search to a single mount point.

For example, my laptop runs cvsupd. If I want to know where this program writes its log files, I can shuffle through the startup scripts, configuration files, and man pages to find it. Or, I can simply look to see which files it has open.

# ps -ax | grep cvsupd
  199  ??  Is     0:00.00 cvsupd -e -C 100 -l @daemon -b /usr/local/etc/cvsup -

So, cvsupd has PID 199.

# fstat -p 199
cvsup    cvsupd       199 root /             2 drwxr-xr-x     512  r
cvsup    cvsupd       199   wd /var         40 drwxrwxrwt     512  r
cvsup    cvsupd       199 text /usr     1541084 -rwxr-xr-x  891596  r
cvsup    cvsupd       199    0 /dev         10 crw-rw-rw-    null rw
cvsup    cvsupd       199    1 /var       1759 -rw-rw-r--       0  w
cvsup    cvsupd       199    2 /var       1759 -rw-rw-r--       0  w
cvsup    cvsupd       199    3* internet stream tcp c2ef1100
cvsup    cvsupd       199    4* pipe c2e07000 <-> c2e06f20      0 rw
cvsup    cvsupd       199    5* pipe c2e06f20 <-> c2e07000      0 rw
cvsup    cvsupd       199    6* local dgram c2ebde10 <-> c2ebe000

We're looking for a log file, which will be identified by a number in the fourth column. The third, fourth, and fifth lines are all files. Looking at only these three lines, check the fifth field. The third line is a device (under /dev), so we aren't interested in that entry. That leaves us with the fourth and fifth lines, which both have something open under /var. The sixth field is the inode of the open file. For both lines, this is inode 1759.

# find -x /var -inum 1759

I never would have guessed to look there. Fortunately, with fstat, you don't have to guess.

Michael W. Lucas

Read more Big Scary Daemons columns.

Return to the BSD DevCenter.

Sponsored by: