When it comes down to it, /proc is a filesystem. Although it does not represent any physical device, you can still mount it and unmount it as you please. It contains a multitude of valuable information regarding the processes you are running, as well as the hardware you have hooked up to your computer (although in recent years, /sys has been devised by the Kernel folks to represent the hardware hierarchy and export device information ). You can see which modules you have loaded, how long your system has been up, and the memory usage of processes on your system. In fact, every single process running has an entry, or directory, inside /proc. As you can see, /proc can be a very powerful asset. But before you can use it, you need to mount it.
Note: Many of the examples in this guide require root access to work correctly. If you don't have root access on your Linux box, get it. We'll wait.
{mospagebreak title=Mounting /proc}
Mounting /proc
As mentioned earlier, /proc is a filesystem. And, like all filesystems, you need to mount it. In theory, you could mount it anywhere, but the standard is to mount it in /proc.
Most systems have /proc mounted by default in /etc/fstab, but just in case, make sure that it's mounted by doing:
$ mount
Note: Throughout this guide, $ indicates a command to be run from a normal user's shell, and # indicates something that must be run from a root shell.
If the output contains a line such as:
proc on /proc type proc (rw)
then you are fine. If not, follow the instructions below.
First, make sure that you have a directory called /proc:
# if ! test -f /proc
then
mkdir /proc
fi
Then, add a line to the file /etc/fstab such as this:
proc /proc proc defaults 0 0
Now, mount it:
# mount proc
You're now ready to play around with /proc.
{mospagebreak title=Viewing Process Information}
Each time a new process is created, an entry in /proc is created. The name of the directory entry corresponds to the process identification number (PID) of the created process, so, for example, a process with a PID of 8695 will have a corresponding directory entry of /proc/8695/.
nside /proc/8695/ (replace 8695 with a real PID on your system), you'll see something like:
auxv exe mem root statm
cmdline fd/ mounts seccomp status
cwd loginuid oom_adj smaps task/
environ maps oom_score stat wchan
Note: The entries ending in �/� are directories.
As you can see, a lot of data about each process is stored. Let's go through the basics:
cmdline - This contains information about the actual command line invoked to start this process. This is a down and dirty way to find out what this process is actually doing.
The best way to access this info is by using a tool such as 'strings' which will display any printable information from a binary file:
$ strings cmdline
/opt/OpenOffice.org/program/soffice.bin
private:factory/swriter
cwd - This is a symlink to the working directory from which the process was started. For example, I started OpenOffice.org (PID 8695) in my home directory, so cwd points to /home/akissner.
environ - This file contains the environment of the process, sorted in to key=value pairs. There is no particular order, so for a human readable output, you would want to do something like:
$ strings environ | sort | less
This will sort the output alphabetically, sorted by the
key.
exe - 'exe' is another symlink, this time to the actual binary itself. So if you wanted to run another copy of the process, you could do:
$ /proc/8695/exe
fd/ - This is a tricky one. It is a subdirectory of symbolic links to open file descriptors in use by the program. /proc/XXXX/fd/ will always contain, at the very least, the links 0, 1, 2. These correspond to STDIN, STDOUT, and STDERR, respectively.
Using this, you can see what files a program is manipulating. This is one way that you can find out where a browser keeps its cache, or a text editor keeps its temporary files.
loginuid - A little background is required before I can explain this one. This isn't completely technically correct, but it's good enough for a Cliff Notes summary.
Each process is represented in the kernel as a structure of type "task". This task structure keeps track of a lot of information about a process, including the PID, the UID of the user who started it, its children, and countless other things. One such attribute is the field "loginuid". The loginuid shows which account a user gained access to the system with. The /proc/XXXX/loginuid shows this value.
maps - 'maps' is one of the most complicated things inside of the /proc filesystem. Suffice it to say that one must have a basic grounding in the inner workings of the kernel and memory management to fully appreciate the information inside of /proc/XXXX/maps.
08048000-080a1000 r-xp 00000000 08:06 35310321 /opt/OpenOffice.org/program/soffice.bin
080a1000-080a6000 rw-p 00058000 08:06 35310321 /opt/OpenOffice.org/program/soffice.bin
080a6000-084b6000 rw-p 080a6000 00:00 0 [heap]
b0e2d000-b0e3d000 rwxp b0e2d000 00:00 0
b0e4d000-b0e81000 r--p 00000000 08:06 86555296 /opt/OpenOffice.org/help/en/picture.db
b0e81000-b0ec4000 rw-p b0e81000 00:00 0
b0ec4000-b0f34000 rwxp b0ec4000 00:00 0
b0f42000-b0f62000 rwxp b0f42000 00:00 0
b0f62000-b0f7d000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b0f7d000-b0f98000 r--s 00000000 00:07 21004324 /SYSV00000000 (deleted)
b0f98000-b0fb3000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b0fb3000-b0fce000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b0fce000-b0fe9000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b0fe9000-b1004000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b1004000-b101f000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b101f000-b103a000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b103a000-b1055000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b1055000-b1070000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b1070000-b108b000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
b108b000-b10a6000 r--s 00000000 00:07 20971555 /SYSV00000000 (deleted)
Shown above is a sample listing for my OpenOffice.org process (PID 8695). As you can see, OpenOffice.org uses a lot of memory!
The first column lists, in hexadecimal, the address range for the mapped memory. The next column lists the permissions on that section of memory. This can either be
r,
w,
x,
p, or
s, which is read, write, execute, private, and shared, respectively. The third column is the offset, and the fourth column lists the device where the memory is mapped from. The device column is split into
major:minor, where major is the corresponding major device number (this has to do with which driver is assigned to which device) and minor number (which has to do with the number of devices a driver is representing). Using information from /proc/devices, you can decipher the device being used. The next column is the inode number of the file from which the memory is being mapped. Last is the pathname of the file.
mem - This cannot be used directly from the command line for anything. You can call the open() and read() system calls on it to read the pages of a process's memory, but most people will go their whole life without ever needing to to this.
mounts - In most cases, this is the same thing as /proc/mounts, which displays mounted filesystem information.
oom_* - These files control the system's behavior if it meets an Out of Memory (OOM) condition. Generally, you won't need to mess with this. The oom_adj file can be used to make a process unkillable during OOM.
root - This is a symlink to the process's root directory. Normally, this will be '/'. But if, for example, a process were started inside a 'chroot jail', then /proc/XXXX/root might point to "/foo/jail".
seccomp - Changing the value in this file from '0' to '1' will send the process in to "seccomp" mode. Seccomp is a sandbox mechanism for the kernel, which restricts a certain process from executing most system calls. This is a security feature, which you will probably never use.
smaps - This file provides detailed memory consumption information for a process.
stat - Like the name suggestions, /proc/XXXX/stat contains information about a process's status. In fact, modern versions of ps (namely those coming from the 'procps' package) use /proc/XXXX/stat for their information. The output is not formatted, and looks like this:
8695 (soffice.bin) S 8666 3234 3180 1025 3224
8396864 68 0 8 0 27 31 0 0 16 0 1 0 51495018 134680576 8844
4294967295 134512640 134875180 3216856352 4154390430 582 0
0 4096 2076206327 0 0 0 33 1 0 0
The best place for information on these fields is the proc(5) manpage.
statm - This file gives memory status information. This file gives information in page-sized blocks. The columns are size (total), rss (resident set size), shared pages, text (the executable code), library code, data/stack size, and dirty pages. The last column is no longer used in the 2.6 kernel series.
status - This file contains the information given in stat and statm, but in a much more human-friendly form. Each row is labeled, and the names are for the most part self-explanatory.
task - task is a directory, containing a directory (with the same name as the PID) that contains all the information inside /proc/XXXX (except for task/). It's a bit of a pointless directory, in my opinion.
wchan - The WCHAN data for a process is the kernel function where the process is currently blocking.
That covers things for this first installment in a multi-part series on understanding the /proc filesystem. Part 2 will cover using /proc to find information about the devices attached to your system.
