Open Source

Process administration in Linux

Want to make administration of your Linux system less of a chore? Jim McIntyre can help. In this Daily Feature, he introduces you to the basics of process management.

Any time you run a program on a Linux system, an instance of that program is loaded into memory. When a program is loaded into memory, it becomes a running task on your Linux system. Because processes consume system resources, such as memory, CPU time, and disk space, being able to manage processes is an important administrative skill. The state of a Linux system at any given time, or any computer system for that matter, is determined by the process running on the system at that moment. In this Daily Feature, I’ll provide an introduction to process management on a Linux system.

Starting processes in Linux
Before we get too involved in processes, I'd like to explain some concepts. Below are the main processes and their explanations.

When a Linux system is booted, lilo.conf loads the kernel. The kernel in turn runs the init program, which is the first process to run on the system. Depending on the system's run level, init may then start other processes. Every process on a Linux system gets a process identification (PID) number. Because init is always the first process loaded into memory, it will always have a PID of 1.

Daemon process
A daemon process is a process that runs continually on your system or is loaded into memory only when asked to do so. During the Linux bootup, several daemon processes are loaded into memory. Some of the more common daemon processes are dhcpd (Dynamic Host Configuration Protocol Daemon), crond (Cron Daemon), and lpd (Line Printer Daemon). A daemon process is usually identified by the letter d at the end of the process name.

User process
A user process, also known as an interactive process, is a process run via a Linux shell. All Linux shells provide a command line where users may enter the names of commands and programs they wish to run. When a user enters a command, e.g., ls -al, or a program like ./install-sh, the shell creates a copy of itself as a new process and replaces the new process with the command or program from the command line. In simple terms, the shell runs the named command or program as another process.

Parent and child processes
A parent process is any process that starts, or spawns, another process. A parent process controls all of its child processes. A child process is any process that is initiated by another process. A child process can also be spawned by its parent process. Let's say you're working in X Windows System and you open an xterm (terminal emulator). From the xterm, you run the command find ~ -name *jpg to find all .jpg files in your home directory. In this example, the terminal window is the parent process of the find command. If the terminal window is closed, the find command is killed. This is because the find command was run as a child process of the term process. Stopping a parent process automatically stops the child process, so when the term window is closed, the find command process stops running.

The ps command
The ps command is used to produce a report of all processes running on a Linux system. If I run ps on my system, I get the following output:
670 pts/0  00:00:00 bash
673 pts/0  00:00:00 ps

In this example, ps shows that I am running two processes: the bash shell, and the ps process itself. The headers at the top of the ps output define the information being shown in each column. The output fields for the ps command are as follows:
  • USER or UID—Process owner
  • PID—Process identification number
  • %CPU—CPU utilization of the process
  • %MEM—Percentage of memory (in kilobytes) used by the process
  • SIZE—Size (in kilobytes) of virtual memory used by the process
  • RSS—Resident set size or size of real memory used by the process
  • TTY—Terminal (console) associated with the process
  • STAT—Current state of the process
  • START—Process start time or date
  • TIME—Total CPU time used by the process
  • COMMAND—Command being executed
  • NI—The nice priority number
  • PRI—Process priority number
  • PPID—Process ID (PID) of the parent process
  • WCHAN—Name of the kernel process where a process is sleeping
  • FLAGS—Numeric flag associated with the process

ps command line arguments
The ps command will accept a wide variety of command line arguments. Some of the most common arguments are:
  • a—Show processes belonging to all users
  • e—Show process environment variables after the command line field
  • l—Output in long format
  • u—Show user name and process start time
  • U—Show processes being run by a specific user
  • w—Show process associated with a specified tty device
  • a –Group—Show all processes belonging to a particular group
  • T—Show all processes associated with this terminal
  • t—Show processes belonging to a specific terminal
  • C—Show all process associated with a specific command

To find all processes belonging to user Jane, the syntax is:
ps U jane

To find all processes for all users, the syntax is:
ps aux

To find the parent process of another process, the syntax is:
ps -l "PID"

PID is the process identification number of the process you wish to find the parent. To find which environment variables are available for a process, the syntax is:
ps e

The environment is appended to the COMMAND field. To find all processes being run by the group Web, the syntax is:
ps a —Group web

Signaling processes
A signal is simply a way of telling a process to do something it would not normally do. For example, to kill a process, the user could send the kill signal to the process. Kill is capable of much more than just terminating processes, however. To see the command line options available to the kill command, type
kill -l

at the command prompt. The output is a list of the options for the kill command. Some of the more commonly used options are:
  • SIGHUP—Hang up. This is used to make a process reload configuration files.
  • SIGINT—Interrupt.
  • SIGQUIT—Quit.
  • SIGTRAP—Trace trap.
  • SIGKILL—Kill. This signal cannot be caught, blocked, or ignored.
  • SIGTERM—Software termination. This is often sent before a KILL signal is sent.
  • SIGSTOP—Stop. This signal cannot be caught, blocked, or ignored.

To catch a signal means the signal is handled in a process. To use the kill command, the syntax is:
kill # PID

Example (Let's assume Netscape is running as process # 670):
kill -9 670

would kill Netscape unconditionally.

The killall command
The killall command lets the user specify a process by name. For example, to kill all instances of Netscape type:
killall netscape

Be careful when using the killall command. Let's say you're using instances of the Emacs editor, running one to edit the file foo.txt and the other to edit /etc/passed. Say you want to kill the instance of Emacs used to edit foo.txt, and you use the command kill emacs. Now, both the instance of Emacs used to edit foo.txt, and the instance used to edit /etc/passed will be terminated. This could result in the loss of any changes you have made to important files.

Running a process in the background
When a command is run from the console it is normally run in the foreground. Running a process in the foreground means that you have to wait for the process to finish before you can initiate another process. However, when a process is run in the background, another process can be run simultaneously. A process is run in the background by adding an ampersand (&) at the end of the command line, as in the example below:
find /etc -name *.conf > ~/conf-file &

This would find all files in the /etc directory and write the output to a file named conf-files in the user's home directory. This process would be run in the background, allowing the user to perform other tasks while this command is being executed.

Once the user is familiar with how Linux handles processes, administering a Linux system becomes much less of a chore. I hope that this simple introduction has helped you understand the underlying principle behind the Linux process so that running a Linux command will not be such a hassle to you as a new user.

Jim McIntyre has been training users on IT-related subjects since 1988. He began his training career as a sonar operator in the Canadian Navy. After retiring early from the military in 1996, Jim completed the Novell CNE program, the Adult Education program at Saint Francis Xavier University, and the Webmaster Program at Dalhousie University. He also graduated from the Train the Computer Trainer program at Dalhousie, where he now serves as a contract instructor. Jim has extensive technical support experience, and he tries to see technical problems as training opportunities. If Jim had a motto, it would be: "Share what you know; learn what you don't." He didn't come up with that phrase, but he likes it.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks