1 Unix/Linux ProcessesIndex

Programs are loaded into memory and run as individual processes. The operating system arranges to share the CPU(s) among all the processes so that each process appears to run independently and concurrently. Some programs can themselves split into multiple threads, each of which gets its own CPU resources.

The operating system has methods to increase or decrease the amount of CPU or Input/Output (I/O) resource a process can consume. System administrators may adjust process priority to reduce the impact a very resource-intensive process is having on the system.

A process usually runs with the userid and group permissions of the person who started it. (Recall that when you log in, you have one user permission and multiple group permissions.) Only the user who owns the process (and, of course, root) can terminate or adjust the priority of a process.

Every process except the very first Unix process starts by forking itself from some parent process. A parent process may fork off multiple child processes, which may themselves fork off more child processes. This gives processes a tree-like hierarchical structure of multiple generations of parents and children.

Each process has a numeric process ID or PID and a parent process ID or *PPID. You can see these two numbers using thel option tops**:

$ ps l

When a parent process exits (terminates) before its children, the children are orphaned and are passed to be children of Unix process Number One (1), traditionally named init:

$ ps l 1
F UID PID PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY TIME COMMAND
4   0   1    0  20   0 24684 2120 poll_s Ss   ?   0:03 /sbin/init

2 Process listing and controlIndex

You can usually list and see the process IDs of all processes on a Unix/Linux system, but you can only control (terminate, pause, or adjust the priority of) your own processes (processes with the same userid as you).

The “ps” command on Linux is a mix of the BSD “ps” command and the incompatible SystemV UNIX “ps” command. From “man ps”:

This version of ps accepts several kinds of options:
  1   UNIX options, which may be grouped and must be preceded by a dash.
  2   BSD options, which may be grouped and must not be used with a dash.
  3   GNU long options, which are preceded by two dashes.

Processes can be paused (stopped) or terminated by their owners (and root). Termination is done by sending a signal to the process id using the poorly-named kill command. The default signal is TERM (terminate), and it allows a process to clean up before terminating. (For example, vim will save its buffers in a *.swp recovery file before exiting.) If TERM doesn’t kill a process, other signals to try are HUP and finally KILL:

 $ kill 123        # or kill -TERM 123
 $ kill -HUP 123   # stronger signal
 $ kill -KILL 123  # or kill -9 123 - strongest signal

Here are the most useful options for these commands:

 $ ps        # BSD: some of your processes (in current window)
 $ ps x      # BSD: all of your processes 
 $ ps xl     # BSD: all your processes, long format
 $ ps xlww   # BSD: all your processes, long format, full wide listing
 $ ps ax     # BSD: all processes for all users
 $ ps laxww  # BSD: all processes, all users, long format, full wide listing
 $ ps f      # BSD: ascii art hierarchical display (forest)
 $ ps -e     # UNIX: all processes
 $ ps -elww  # UNIX: all processes, long format, full wide listing
 $ pstree    # process tree; similar to "ps axf"
 $ kill      # send TERMinate signal to a process ID or job number
 $ killall   # send TERMinate signal to a process with a given name
 $ jobs      # show child processes **only of the current shell**

Note that the killall command is somewhat dangerous, since by killing processes based on name it might match unintended names. (If an attacker decides to name an attacking program bash, then killall -9 bash would not be a good thing to type.)

• Q: how do you see all your processes?
• Q: how do you see all processes for all users?
• Q: how do you terminate a process?
• Q: how do you terminate a process using the strongest signal?

3 Unix/Linux Shell Job Control and Background ProcessesIndex

The shells often provide some added syntax that lets you manage processes that are forked from that shell. Processes forked from the current shell are called the jobs of the shell.

Normally when you run a command, the shell waits until the command is finished before it prompts you to enter the next command. This is called a “foreground” job. The foreground job is attached to your keyboard and screen (unless you have redirected input or output).

You can interrupt most foreground jobs using the ^C (Ctrl-C) key:

$ sleep 99
^C
$

If you want to run a command “in the background”, without having the shell wait for it to finish, end the command with an ampersand &, e.g.

$ sleep 99 &
[1] 18920
$

The & starts the job without requiring the shell to wait for it. The shell gives you a prompt for your next command immediately. The background command runs independently, and any output it produces will appear on your terminal screen, mixing with whatever else you are typing.

$ ( sleep 3 ; date ) &
[1] 4157
$ 
$ Mon Nov 26 04:51:18 EST 2012

You can type ^L at the shell to clear your screen of output.

If a background job tries to read from your keyboard, the system will pause (“STOP”) that job until you make it foreground again:

$ wc &
[1] 1538
$ jobs -l
[1]+  1538 Stopped (tty input)     wc
$ fg
wc
The wc command is now foreground and reading my keyboard.
^D
1  10  59
$ 

The shell ensures that only one job is “foreground” and reading your keyboard. All other jobs that try to read the keyboard will be paused (“Stopped”). (When the shell isn’t running any commands, the shell has your keyboard.)

$ sleep 99
^Z
[1]+  Stopped                 sleep 99
$ bg
[1]+ sleep 99 &

$ jobs
[1]+  Running                 sleep 99 
$ fg
sleep 99

$ jobs
[1]+  Running                 sleep 99 

$ kill %1
[1]+  Terminated              sleep 99

4 setuid files - privileged processesIndex

Some privileged setuid programs can run with the userid and/or group of the file containing the program, instead of the user and/or group of the person starting the process. You can see the setuid bit set as an s in an ls -l listing:

$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 22648 Sep 14  2009 /usr/bin/passwd

The above passwd command will start up and run as the root user, not as the user who starts the command.