Introducing UNIX and Linux

Processes and devices

Overview
Processes
      Process status
      Foreground and background
      Process control
      Signals
Environment
      Environment variables
      Global and local variables
      Executable scripts
Program control
      Job control
      Command history list
      Running a job at a specific time
      Running programs periodically
      Big programs
      Timing a program
      Running programs in order
Quotes and escapes
Devices
Backquotes
Summary
Exercises

Signals

The kernel controls many processes, created by possibly many users, and including many that are 'system' processes, necessary for the system to function. The kernel allows these processes to communicate by sending 'messages' to each other. Any process in the system can send a message to any other process, and because there could be many processes and many messages being sent, UNIX restricts the messages to being very simple.

These messages are known as signals, and each takes the form of a single byte. They are instructions to processes, such as kill (cease running immediately) and stop (become a suspended process). Signals are concerned with the scheduling of processes, that is, when and in which order they are executed. The command kill, so named because the most commonly used signals that a user invokes will destroy a process, is provided for a user to send a signal to a specific process. A detailed discussion of signals is beyond the scope of this chapter, but one particular signal is important at this stage.

The signal SIGKILL, when received by a process, causes it to be destroyed immediately. For example, to kill the sleep process above, you could type

$ kill -s KILL 16403

where kill with option -s ('signal') causes the signal named after -s to be sent to the process whose PID is given as the final argument to kill. Note that, although this signal is referred to as SIGKILL, only the word KILL is passed to the command kill. This is because all signals are called SIGsomething, so the SIG is redundant in any context where the name of a signal is expected. There are many other signals, such as SIGHUP and SIGTTIN, some of which will be discussed later on.

This raises the question of why you might ever wish to destroy a process. It sometimes happens that a process that is running in the background is left there by mistake, for instance if the software that created it was poorly written. It also happens sometimes that you send a program to run in the background when you think it will run for a long time, and later on discover that because of an error in the program it is failing to finish.

It is important to remember that UNIX uses processes as its most basic concept of a 'program'. Remembering PIDs can be tedious, however. A more 'user-friendly' method of handling processes, called job control, is available, which we now introduce.