FreeBSD Handbook
Prev | Chapter 3 UNIX Basics | Next

# 3.7 Processes

FreeBSD is a multi-tasking operating system. This means that it seems as though more than one program is running at once. Each program running at any one time is called a process. Every command you run will start at least one new process, and there are a number of system processes that run all the time, keeping the system functional.

Each process is uniquely identified by a number called a process ID, or PID, and, like files, each process also has one owner and group. The owner and group information is used to determine what files and devices the process can open, using the file permissions discussed earlier. Most processes also have a parent process. The parent process is the process that started them. For example, if you are typing commands to the shell then the shell is a process, and any commands you run are also processes. Each process you run in this way will have your shell as its parent process. The exception to this is a special process called init(8). `init` is always the first process, so its PID is always 1. `init` is started automatically by the kernel when FreeBSD starts.

Two commands are particularly useful to see the processes on the system, ps(1) and top(1). The `ps` command is used to show a static list of the currently running processes, and can show their PID, how much memory they are using, the command line they were started with, and so on. The `top` command displays all the running processes, and updates the display every few seconds, so that you can interactively see what your computer is doing.

By default, `ps` only shows you the commands that are running and are owned by you. For example:

    % ps
      PID  TT  STAT      TIME COMMAND
      298  p0  Ss     0:01.10 tcsh
     7078  p0  S      2:40.88 xemacs mdoc.xsl (xemacs-21.1.14)
    37393  p0  I      0:03.11 xemacs freebsd.dsl (xemacs-21.1.14)
    48630  p0  S      2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi
    48730  p0  IW     0:00.00 (dns helper) (navigator-linux-)
    72210  p0  R+     0:00.00 ps
      390  p1  Is     0:01.14 tcsh
     7059  p2  Is+    1:36.18 /usr/local/bin/mutt -y
     6688  p3  IWs    0:00.00 tcsh
    10735  p4  IWs    0:00.00 tcsh
    20256  p5  IWs    0:00.00 tcsh
      262  v0  IWs    0:00.00 -tcsh (tcsh)
      270  v0  IW+    0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16
      280  v0  IW+    0:00.00 xinit /home/nik/.xinitrc -- -bpp 16
      284  v0  IW     0:00.00 /bin/sh /home/nik/.xinitrc
      285  v0  S      0:38.45 /usr/X11R6/bin/sawfish

As you can see in this example, the output from ps(1) is organized into a number of columns. `PID` is the process ID discussed earlier. PIDs are assigned starting from 1, go up to 99999, and wrap around back to the beginning when you run out (a PID is not reassigned if it is already in use). The `TT` column shows the tty the program is running on, and can safely be ignored for the moment. `STAT` shows the program's state, and again, can be safely ignored. `TIME` is the amount of time the program has been running on the CPU--this is usually not the elapsed time since you started the program, as most programs spend a lot of time waiting for things to happen before they need to spend time on the CPU. Finally, `COMMAND` is the command line that was used to run the program.

ps(1) supports a number of different options to change the information that is displayed. One of the most useful sets is `auxww`. `a` displays information about all the running processes, not just your own. `u` displays the username of the process' owner, as well as memory usage. `x` displays information about daemon processes, and `ww` causes ps(1) to display the full command line for each process, rather than truncating it once it gets too long to fit on the screen.

The output from top(1) is similar. A sample session looks like this:

    % top
    last pid: 72257;  load averages:  0.13,  0.09,  0.03    up 0+13:38:33  22:39:10
    47 processes:  1 running, 46 sleeping
    CPU states: 12.6% user,  0.0% nice,  7.8% system,  0.0% interrupt, 79.7% idle
    Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free
    Swap: 256M Total, 38M Used, 217M Free, 15% Inuse

      PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
    72257 nik       28   0  1960K  1044K RUN      0:00 14.86%  1.42% top
     7078 nik        2   0 15280K 10960K select   2:54  0.88%  0.88% xemacs-21.1.14
      281 nik        2   0 18636K  7112K select   5:36  0.73%  0.73% XF86_SVGA
      296 nik        2   0  3240K  1644K select   0:12  0.05%  0.05% xterm
    48630 nik        2   0 29816K  9148K select   3:18  0.00%  0.00% navigator-linu
      175 root       2   0   924K   252K select   1:41  0.00%  0.00% syslogd
     7059 nik        2   0  7260K  4644K poll     1:38  0.00%  0.00% mutt
    ...

The output is split into two sections. The header (the first five lines) shows the PID of the last process to run, the system load averages (which are a measure of how busy the system is), the system uptime (time since the last reboot) and the current time. The other figures in the header relate to how many processes are running (47 in this case), how much memory and swap space has been taken up, and how much time the system is spending in different CPU states.

Below that are a series of columns containing similar information to the output from ps(1). As before you can see the PID, the username, the amount of CPU time taken, and the command that was run. top(1) also defaults to showing you the amount of memory space taken by the process. This is split into two columns, one for total size, and one for resident size--total size is how much memory the application has needed, and the resident size is how much it is actually using at the moment. In this example you can see that Netscape® has required almost 30 MB of RAM, but is currently only using 9 MB.

top(1) automatically updates this display every two seconds; this can be changed with the `s` option.

Prev | Home | Next
Mounting and Unmounting File Systems | Up | Daemons, Signals, and Killing Processes