Using the crash(ADM) diagnostic tool

Finding out which files a process has open

It is sometimes useful to be able to find out which files a process has open. This may be because a program will run on one system but not on another. You may suspect that the permissions on a file or directory are preventing the program from running but you are uncertain as to which files it uses. ``The relationship between the file descriptor table of a process and the system open file and in-core inode tables'' shows how entries in the file descriptor array (u_ofile[]) in each process's u-area point to entries in the open file table. Each entry in the open file table points to an entry in the generic in-core inode table. Note that a slot number in the in-core inode table is not the same (unless coincidentally) as the inode number of the associated file in the filesystem.

The relationship between the file descriptor table of a process and the system open file and in-core inode tables

To find which files are open to a process, you must trace a path from the file descriptor table of a process to the in-core inode table. You can then use the nodnm(ADM) and ncheck(ADM) commands to find the filesystem to which the inode belongs and to relate one or more filenames to the inode.

Use the proc command to find the slot number of the process in which you are interested. On a live system, you can also use the ps(C) command to discover the process' ID number (PID).
Use the curproc command to define the process as the current process:

> curproc slot
Procslot = slot
or

> curproc #PID
Procslot = slot
Use the user command to show which entries in the system file table are pointed to by the process' file descriptors:

> user
PER PROCESS USER AREA FOR PROCESS slot
...
OPEN FILES AND POFILE FLAGS:
[ 0]: F#3 [ 1]: F#10 w [ 2]: F#10 w
[ 3]: F#7 r
...
The standard input (file descriptor 0) references entry 3 in the file table. Both the standard output and standard error output have opened entry 10 (file descriptor 2 is a duplicate of file descriptor 1), and file descriptor 3 references entry 7. The r and w flags show if the process has the files open for reading or writing, or both; the c flag shows a file descriptor that will be closed on an exec(S) system call.

Use the file command to find the in-core inode numbers for file table entries 3, 10, and 7:

> file 3 10 7
FILE TABLE SIZE = 341
SLOT  RCNT   I/FL      OFFSET  FLAGS
   3     1 I# 267           0 read
  10     4 I# 291          94 write append
   7     1 I#   2           0 read write

Use the inode command to find the inode number and filesystem major and minor device numbers corresponding to each in-core inode number:
```
> inode 267 291 2
INODE TABLE SIZE = 161
SLOT MAJ/MIN FS INUMB RCNT LINK   UID   GID     SIZE    MODE MNT M/ST FLAGS
 267   1,40   1    45    7    1     0     3        0 c---666   0 S  0  -
 291   1,40   1    46    1    3     2    15        0 c---600   0 S  0  -
   2   1,40   1   171    1    1     9    16        0 p---060   0 S  0  -
```
From this, it can be seen that the in-core inode slot 267 refers to inode number 45 in the filesystem whose device node has major and minor device numbers 1 and 40. Other information that may be of interest is that inode number 46 has three hard links that reference it (LINK = 3), and inode number 45 has seven references to it in the file table (RCNT = 7).
The modes for both inodes 45 and 46 begin with ``c''; this shows that the files are character special devices. Inode 171's mode begins with a ``p'' indicating that it is a named pipe. A regular file's mode would begin with a ``f''; see the ls(C) manual page for a list of other mode character codes.
You can find the filesystem corresponding to the displayed major and minor device numbers using nodnm(ADM):
```
> !/etc/nodnm b 1 40
/dev/root
> !/etc/nodnm c 1 40
/dev/rroot
```
This shows that the filesystem that corresponds to device major number 1 and minor number 40 is /dev/root.

The names corresponding to inodes 45, 46, and 171 in /dev/root can be found using the ncheck(ADM) command:

> !ncheck -i 45 46 171 /dev/root
/dev/root:
45   /dev/null
46   /dev/console
46   /dev/syscon
46   /dev/systty
171  /usr/lib/cron/FIFO

From the above information, we can conclude that the process has opened the following files:

/dev/null on the standard input (file descriptor 0).
/dev/console on the standard output and standard error output (file descriptors 1 and 2). The standard error output descriptor is a duplicate of that for the standard output; both descriptors share the same open file, file pointer, and access modes. If the standard error output had opened this file separately, it would have its own entry in the file table rather than sharing one with the standard output.
/usr/lib/cron/FIFO on file descriptor 3.