UNIX System Administration Handbook - Evi Nemeth [47]
The exact number of possible letter codes varies from system to system. The most common codes are c for a process that has its current directory on the filesystem, o for an open file, t for a running program, m for a mapped file (shared libraries, usually), and r for a process whose root directory is on the filesystem (set with chroot).
To determine exactly what the offending processes are, just run ps with the list of PIDs returned by fuser. For example,
% ps -fp "157 315 5049"
UID PID PPID C STIME TTY TIME CMD
root 5049 490 0 Oct 14 ? 0:00 /usr/bin/X11/xdm
root 157 1 0 Jun 27 ? 5:26 /usr/sbin/named
lp 315 1 0 Jun 27 ? 0:00 /usr/lib/lpsched
The quotation marks force the shell to pass the list of PIDs to ps as a single argument.
fuser can also report on the use of specific files (as opposed to entire filesystems); the syntax is fuser -f filename. fuser also allows -k to kill (or send a signal to) each of the offending processes. Dangerous—and you must be root (or use sudo).
Red Hat’s fuser, by Werner Almesberger, uses -m instead of -c. To report on individual files, just omit the -m option. Red Hat’s fuser also has a nifty -v option that gives ps-like output:
% fuser -mv /usr
USER PID ACCESS COMMAND
/usr root 1 ....m init
root 125 ....m apmd
root 274 ....m portmap
root 321 ....m syslogd
FreeBSD does not have the fuser command, but it does provide fstat, which has similar capabilities.
Another alternative to fuser is the free lsof utility by Vic Abell of Purdue University. In fact, lsof’s output is rather more informative and usable than that of fuser. lsof is available from
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/
It works on all of our example systems.
5.3 THE ORGANIZATION OF THE FILE TREE
The UNIX filesystem has never been very well organized. Various incompatible naming conventions are used simultaneously, and different types of files are scattered randomly around the namespace. In many cases, files are divided up by function and not by how likely they are to change, making it difficult to upgrade the operating system. The /etc directory, for example, contains some files that are never customized and some that are entirely local.
Innovations such as /var have helped to solve a few problems, but most systems are still a disorganized mess. Nevertheless, there’s a culturally correct place for everything. Most UNIX software can be installed with little reconfiguration if your system is set up in a standard way. If you try to improve upon the default structure, you are asking for trouble.
The root filesystem includes the root directory and a minimal set of files and subdirectories. The file containing the kernel lives in the root filesystem. It’s usually called unix or vmunix; it can be right in the root directory or secreted in a subdirectory such as /kernel or /stand. Also part of the root filesystem are /dev for device files, /etc for critical system files, /sbin and /bin for important utilities, and sometimes /tmp for temporary files.
See Chapter 12 for more information about configuring the kernel.
Some systems keep shared library files and a few other odd things such as the C preprocessor in the /lib directory. Others have moved these items into /usr/lib, sometimes leaving /lib as a symbolic link.
The directories /usr and /var are also of great importance. /usr is where most standard programs are kept, along with various other booty such as on-line manuals and libraries. It is not strictly necessary that /usr be a separate filesystem, but for convenience in administration it almost always is. Both /usr and /var must be available in order for the system to come up all the way to multiuser mode.
/var provides a home for spool directories, log files, accounting information, and various other items that grow or change rapidly and vary on each host. Since /var contains log files, which are apt to grow in times of trouble, it is a good idea to put it on its own filesystem if that is practical.
Most of the contents of /var originally lived in /usr; on your