Introducing Processes

Did you ever had some program 'hanging' on you? Indeed 'hanging' so badly that it gobbled up all system resources, slowing down all operations to a crawl? And didn't you wish there were just a way to kill that damn thing? Were you ever interested in knowing how much system resources a program uses?

Well, you have come to right place, then :-). What are processes? Basically everything going on on your system: your web browser is a process, your web server - if you happen to run one - is also a process. A process boots your machine and another shuts it down. Every tiny script starts a process, albeit usually a very short one. "A process" says the textbook, "is an instance of a program in execution."

Processes can be started, stopped, killed, given priorities, scheduled. You do many of these actions already without knowing about it: when you open a program, you start a process, by closing the program, you kill the process. It's not some fancy Linux thing either, every modern operation system has them, because processes allow for multi-tasking: by keeping a unified list of what is going on, the operating system can run a schedule, thus providing its user with the illusion of being able to do many things at once.

Usually the operating system,i.e. the kernel, manages processes for you, you only need to interfere if you have special preferences (e.g. want to have a process to get more resources) or if a process goes awry and starts eating all the available system resources.

section index top

Process Monitors

There are graphical interfaces for these programs, however, which you might find more convenient and easier to use: 'ksysguard' (package 'kdeadmin', menu: Applications - Monitoring - KDE System Guard), 'kpm' (package 'kdeutils', menu: Applications - Monitoring - Process Management) and 'gtop' (package 'gtop', menu: Applications - Monitoring - GTop). 'ksysguard' even allows you to watch and control processes on other machines.

Since all these tools use the same information from the '/proc' directory (more on that later), they all display processes and their attributes in similar fashion.
If you open them, you'll find a dynamic (apart from 'ps') column display with a row for each process. Columns are:

• PID: This is the Process IDentification number. To the system, processes are not known by their name, but by a unique number. Each new process gets a higher PID. The more processes you run and / or the longer your machine runs, the higher those numbers get. That's normal.

• User (also Login): The user who 'owns', i.e. started this process. Users can only manipulate processes they own. Only 'root' can manipulate all processes.

• Pri (also Nice or NI): The priority of a process in relation to all other processes. Lower numbers indicatehigher priority. Standard priority is '0'.

• Size (also VSZ or VmSize): Thetotal amount of virtual system memory a process uses. As explained later on, that's by no means a fair indicator of how much memory the process actually uses. Compare next entry.

• Resident (also VmRSS or RSS): The amount of physical system memory a process uses up. This is more accurate for measuring how much system memory a process needs.

• Stat (missing in 'ksysguard'): The status of a process. Sane processes are either 'R'unning or 'S'leeping. It is normal that only one process is displayed as 'running' at any given time while the others are 'sleeping' (i.e. waiting for a signal).

• CPU (subdivided in User% and System%by 'ksysguard'): Percentage of the processor time taken up by the process since the last display refresh.

• MEM: Percentage of physical system memory consumed by the process.

• Time (missing in 'ksysguard'): Total amount of processor time the process has used since started.

• Command (also Cmd): Command name of the process.

Manipulating processes via the graphical utilities usually just involves 'highlighting' the process you want to handle and using the right mouse button click context menu. 'top' is controlled via shortcut keys, read man top for a list.

Notice that there's a standard key combination for killing graphical applications, <ALT> <CTRL> <ESC>. This will change the mouse pointer to a 'death' symbol. Click on an application window and that application will be killed. You still want to check if the processes of that application had been killed, too, though.

section index top

Processes In Detail

The father of all processes is 'init' (initializer). The pstreecommand shows this quite impressively.
'init' manages the runlevels, it controls which processes are started and stopped at which runlevels and it is responsible for bringing the system to these runlevels. If you shutdown your system, you essentially tell 'init' to bring it to runlevel 0. It's the same if you type shutdown -h now or init 0.

Information on current processes is stored in the '/proc' file system. The '/proc' file system consists of kernel data changed in real-time. It is therefore not a 'real' file system like the others: the data contained take up no place on the hard-disk and you can't write to it. But you can extract and change the information contained therein (e.g. using the 'cat' command).

Listing '/proc', you'll find a lot of directories which names only consist of numbers. These numbers are the 'process IDs' (PIDs). If you list such a directory, you'll find files like 'cmdline', which contains the command line the process was started with, or 'stat', which contains number codes on the current process.
For example:

# cat /proc/1/cmdline
init

Which means: 'The process with the PID 1 was started with the command 'init''. 'init' will always be the first process and thus is the only process with a permanent PID. All other processes will have increasing PIDs, the maximum PID being 32768 (although the maximum number of processes on Linux is only limited by the amount of physical memory available).

The children of 'init' can have child processes themselves. If you start a program by typing its name on a command line, the program will be a child of the program which handles the command line. In most cases, this will be 'bash' (the 'Bourne-Again-SHell').
One important thing to know is that child processes 'inherit' some assets of their fathers. If you run a process with 'root' privileges, a child of this process will also have these privileges.

Now you might ask: 'Since init runs with 'root' privileges, and it is the father of all processes, does that mean that all processes and programs on Linux run with root privileges?'

It's obvious they don't do that. Servers like the font server, web servers, mail servers run on their own user account. The font server for example runs on the 'xfs' account, the Apache web server on the 'apache' user account. Servers which don't come with their own user account use the standard 'nobody' user account. These are not 'real' accounts: nobody can login via these so-called system accounts.
The reason for this is security: servers can be accessed from outside the machine. If one of them contains a software flaw which allows attackers to execute commands on your machine as the user who is running the server, it would be a disaster if that user would be 'root'. Notice that this isn't a system mechanism, but a standard feature of Linux servers. You should refrain at all cost from using servers which do not include it.

Another mechanism is the 'login' command. Have a look at the output of 'pstree' again. You will see that every process and program you started after boot is a child of the 'login' process. 'login' switches the permissions of these child processes depending on how you log into the system. If you log in as 'root', all children will have 'root' privileges, if you log in as a user, the children will run with the permissions (the 'UserID', UID) of this user. The latter is preferable for the system's security and stability. If you need 'root' privileges, you can always log into the 'root' account from your user account by using 'su' or 'sudo'.

setUID

As you've already seen, processes can run with a UserID different from the user who started them. Servers are started by 'root' but drop this privilege as soon as possible and run on their own system account. In Unix-speak, one says they are running 'setuid account' (e.g. Apache runs 'setuid apache').

Of course, you can also do that the other way round by providing processes started by a user root privileges.
The most prominent example is the graphical subsystem, 'X'. 'X' needs 'root' privileges to run. However, the children of X do not run as 'root'. How come?
'X' is started via a so-called wrapper, '/usr/X11/bin/Xwrapper'. If you look at the permission bitsof this program, you will see it's 'setuid root':-rws--x--x. This wrapper handles the permissions part when starting X, so that X itself doesn't need to be 'setuid root'. It runs as 'root' but its children don't inherit its UID.

Priority

Processes run either in user mode or in kernel mode. The operating system and its core services run in the privileged kernel mode, whereas 'normal' applications run in user mode, this way badly behaving user processes do not interfere with system operation. Some user processes however need access to privileged kernel functions. For this they switch to kernel mode, execute the needed function and switch back to user mode.

All user processes get the same share on the processor schedule. But you can change that with the nice -n value process command. Negative values increase the priority. They can only be applied by 'root', whereas positive values can be applied by any user.
nice -n value process starts a process with a given priority, the command renice priority PID changes the priority of a running process.

Processes And Threads

A program may open several processes if needed. This however isn't very efficient: each process would need its own address (memory) space and switching between these would cost a considerable amount of system resources. This is where 'threads' come in. Threads are started by a process, but they remain within the original address space used by the process. Switching between threads consumes much less resources than between processes. Applications which use this technique are called 'multi-threaded'.
Programming thread-enabled applications cleanly is very hard which justifies the use of threads only in very complex pieces of software, like the Mozilla browser.

As a system administrator, you only have to know about them thatprocess monitors on Linux can not discriminate a thread from a process. Point in case is the Mozilla browser. If you start it, the process monitors will show multiple entries for it:

tom 11290 13.4 2.3 33080 21124 ? S 11:47 0:02 /usr/lib/mozilla/
tom 11296 0.0 2.3 33080 21124 ? S 11:47 0:00 /usr/lib/mozilla/
tom 11297 0.0 2.3 33080 21124 ? S 11:47 0:00 /usr/lib/mozilla/
tom 11298 0.0 2.3 33080 21124 ? S 11:47 0:00 /usr/lib/mozilla/
tom 11299 0.7 2.3 33080 21124 ? S 11:47 0:00 /usr/lib/mozilla/

                  

This does not mean that the Mozilla browser has started five processes, but that's one process with four threads, all in the same address space. How can one tell? Well, you don't get any real proof, since the monitor doesn't know either, but there are hints like the same memory consumption numbers, the same command name and the same start time. Only thefirst entry is valid when looking at system resource usage.

For more on Linux process management, read the Linux Gazette article Processes on Linux and Windows NT by Glen Flower.

section index top

Accounting, restricting, measuring and killing processes