BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


FreeBSD Basics

Discovering System Processes

11/15/2000

In the next two articles, I'd like to take a look at processes. This week, we'll see what a process is and how to view information regarding your processes. Next week, we'll look at doing useful things with this process information.

Like any other Unix system, FreeBSD is a multitasking, multiuser operating system. This means that a number of users can each be running a number of programs at the same time. It is the kernel's responsibility to ensure that each of these programs gets a fair turn at your computer's CPU and that each user receives the correct results from their program's execution.

When you start a program, it is loaded into RAM and is called a process, as its instructions need to be processed by the CPU. In order for the kernel to keep track of which programs are running and which user started which program, each process is assigned a process ID, or PID. Usually, the PID will be associated with, and have the same permissions as, the user who started the program and that user's primary group.

Not all programs are started by users; some are started by your FreeBSD system at boot time and are called daemons. Also, some programs will either start other programs or other instances of themselves. The original program is called the parent process, and the other processes are called its child processes.

When you installed FreeBSD, the process filesystem, or procfs, was created for you. If you type:

more /etc/fstab

you should see the following lines:

# Device  Mountpoint  FStype  Options  Dump  Pass#
proc      /proc       procfs  rw       0     0

Also, you may have noticed that this filesystem is always 100% full when you display your free disk space like so:

df

Filesystem    Size   Used  Avail Capacity  Mounted on
procfs        4.0K   4.0K  0B    100%      /proc

This is normal, as the process filesystem is not supposed to contain files created by users; instead, it is read by the ps and w commands so they can display which processes are currently running. Notice that the proc filesystem is mounted on /proc. Let's take a look at the contents of /proc using ls with the C switch to sort the display into columns and the F switch to mark directories with a trailing slash:

cd /proc
ls -CF
./      175/     2072/     301/     315/
../     176/     227/      307/     316/
0/      177/     261/      308/     317/
1/      178/     27/       309/     318/
110/    181/     273/      310/     319/
163/    197/     290/      311/     320/
166/    199/     292/      312/     4/
171/    2/       3/        313/     5/
173/    202/     30/       314/     curproc@

Note that every entry except one is a directory whose name is a number; that number refers to the PID of a running process. The last entry, curproc, is a symbolic link since it ends with the @ symbol. To find out what it is linked to, type:

file curproc
curproc: symbolic link to 2072

It would appear that curproc is a symbolic link to another process. If you do a:

man 5 procfs

you'll read that curproc actually refers to the current process making the lookup request; that is, my original ls command had a PID of 2072.

Now, let's see what type of information is recorded for each of the running processes by viewing the contents of one of these directories:

ls -CF 197
./       ctl     file@    mem     regs
../      dbregs  fpregs   note    rlimit
cmdline  etype   map      notepg  status

These all seem to be regular files except for the symbolic link named file; however, we have no idea what type of data they contain. Let's find out:

file *
cmdline: empty
ctl:     empty
dbregs:  MS Windows COFF Unknown CPU
etype:   empty
file:    symbolic link to /usr/sbin/inetd
fpregs:  data
map:     empty
mem:     empty
note:    empty
notepg:  empty
regs:    data
rlimit:  empty
status:  empty

It doesn't look like we'll be able to open up any of these files ourselves as they don't contain readable text. This makes sense for a filesystem that keeps track of data useful to the kernel. Even though you can't view the data directly, you can use the w and ps commands, which do know how to interpret and display the data contained within these files.

Let's start with the w command:

whatis w
w(1) - display who is logged in and what they are doing
w
10:43AM  up 17:50, 4 users, load averages: 0.00, 0.00, 0.00
USER        TTY    FROM      LOGIN@  IDLE WHAT
genisis     v0     -         9:46AM     - w
genisis     v1     -        Sat04PM  2:02 -csh (csh)
genisis     v2     -        Sat08PM     - -csh (csh)
genisis     v3     -        Sat05PM  2:02 -csh (csh)

The first line displays the current time of day, how long your FreeBSD system has been up, the number of users currently logged in, and the number of jobs in the run queue averaged over 1, 5, and 15 minutes.

The remaining lines show the user's login name, the name of the terminal that user is logged in to, the host from which the user logged in, the time the user logged on, the time since the user last typed anything, and the name and arguments of the current process.

If we use the d switch with the w command, we'll receive a slightly different output, as w will display all the processes that user has running on their terminal, like so:

w -d
10:55AM  up 18:02, 4 users, load averages: 0.00, 0.00, 0.00
USER     TTY      FROM     LOGIN@  IDLE WHAT
         2100                           -csh (csh)
         2104                           _su (csh)
         2235                           w -d
genisis  v0       -          9:46AM   - w -d
         313                            -csh (csh)
genisis  v1       -       Sat04PM  2:14 -csh (csh)
         314                            -csh (csh)
genisis  v2       -         Sat08PM   - -csh (csh)
         315                            -csh (csh)
genisis  v3       -       Sat05PM  2:14 -csh (csh)

The numbers under the TTY column are the PIDs of the processes. If you read the manpage for w, you'll find that it is a good utility to get a quick overview of who is currently logged in to which terminals and what they might be doing; however, it was not intended to provide detailed process usage information, as that is the job of the ps utility. If you simply type:

ps

you'll receive basic information on the processes you have started, like so:

  PID  TT  STAT   TIME    COMMAND
 2100  v0  Ss     0:00.13 -csh (csh)
 2286  v0  R+     0:00.00 ps
  313  v1  Is+    0:00.13 -csh (csh)
  314  v2  Is+    0:00.21 -csh (csh)
  315  v3  Is     0:00.12 -csh (csh)

Reading the output from left to right, the default ps displays the PID, the name and type of the terminal, state, cpu time (including both user and system time), and the associated command for processes started by the user who ran the ps command.

State is a new term which can provide valuable information about your running processes. When reading the state (STAT) column, the first letter indicates the run state of the process. The valid values are:

  • D - a process in disk (or other short term, uninterruptible) wait
  • I - an idle process (sleeping for longer than about 20 seconds)
  • J - a process which is in jail(2)
  • R - a runnable process
  • S - a process that is sleeping for less than about 20 seconds
  • T - a stopped process
  • Z - a dead (zombie) process

In my output, I have one running process (the ps command), one c shell that hasn't done anything within the last 20 seconds, and three c shells that haven't done anything in more than 20 seconds. The "+" symbol indicates that three of my processes are foreground processes, and the "s" indicates that four of my processes are session leaders. Don't worry if some of the state information doesn't hold profound meaning for you; some of it won't unless you are a programmer.

Pages: 1, 2

Next Pagearrow





Sponsored by: