08. Processes and Signals (Part 1)
Processes and Signals
- When a script runs, it is a process of the system
- There are many processes running concurrently on the Linux system, and communication with a process is through signals
- A signal can come from the kernel or from another process or from the user through a process
- When a process receives a signal, it can either follow the default reaction to the signal, or it can choose to handle the signal in its own way.
Topics covered in this section
- Processes on the system
- Types of signals
- Responses to signals
- Any program that is running on the Linux system is a process.
- A process consists of the executing program code, a set of resources such as open files, internal kernel data, memory space, one or more threads of execution, and a data section containing global variables.
- Just by logging into linux terminal and idling at the command prompt, you already have 2 processes running: the sshd process (the ssh tool that is your connection to the system) and the bash process (the shell that gives you the prompt)
- Any time you run a command, a child process is spawned from your bash process to execute the command
- If the command is a script that calls another command, then the script is a process, and each command in the script that runs is another process.
- Each process has a unique id in the system called a Process ID or PID
- When you want to communicate to a particular process you need to refer to its PID
- A PID is a number that uniquely identifies a process. It is one field of a control structure for each process
- To see the processes and their PIDs, use: ps
- Without any option, the default of ps shows the processes that you have at the current terminal that you log in:
PID TTY TIME CMD
18306 pts/10 00:00:00 bash
21067 pts/10 00:00:00 ps
- Here are 2 processes running at a particular log in terminal (TTY 10). The PID of the shell is 18306 and the PID of the ps command to show the output is 21067
- A useful option of ps is the u option, which shows all processes that a particular user is running, regardless of which terminal or how many terminals the user logs in.
- If you have several login windows (several terminals) running, the u option with your user id will show all processes that you have running at all terminals: ps u or ps -u userid
- To identify which window is which terminal number, at the window command prompt, use the tty command
Introduction to Signals
Introduction to Signals
- Signals are generated by the kernel, by other processes running on the system, by hardware devices, or by the user when certain keys are pressed
- Example of when signals are generated:
- Some system limit, such as the number of running processes, is exceeded
- A hardware device becomes ready or is shut off
- A divide by zero occurs
- The user hits control-c
- When a signal is generated or is raised, it is sent to a process to alert the process of a condition
- When the process receives or catches the signal, the signal is said to interrupt the process
- This is analogous to when someone calls your phone number. The caller generates a signal designed to go to you, through your phone number. When you receive the call, you are interrupted from what you are doing.
- Based on the conversation of the phone call, you might finish the conversation and then continue with your task from before the phone call. Or the phone call might stop you from doing your current task so that you can do something else
- First we look at a running process without any signal interrupt:
- When a script first starts running, each instruction in the script is executed one by one
- This keeps going until there is no more instruction in the script
- When there is no more instruction, the process is finished and execution returns to the OS
- A running process with a signal interrupt:
- In the middle executing instructions in a script, a generated signal arrives to interrupt the script
- Instead of executing the next instruction of the script, signal handling code (a different set of instructions) is executed
- Each instruction of the signal handling code is also run one by one
- Depending on how the signal handling code is written, at the end of signal handling, execution may or may not return to the script
- For example, if the signal is a control-c from the user, the signal handling code will end the current script. On the other hand, if the signal is for communication between processes, then the process which was interrupted by the signal can continue
- Signals are a way for processes to communicate asynchronously with each other. Each signal tells a process what action is required from that process
- Many signals are generated when you are logged in at the shell Every time you run a command, the shell (parent) process uses signals to communicate with the command (child) process.
- Signals are also generated by the kernel to communicate with the processes
- All signals generated are sent to the kernel, which then routes it to the appropriate process
- If the process is currently running, the kernel routes the signal to the process immediately
- If the process is suspended (stopped), but is interruptible, then the kernel starts it again to route the signal to it
- If the process is not in user mode (when it is in kernel space and has high priority) or is uninterruptible (such as when it is waiting for IO), then the kernel holds the signal until it can deliver it to the process.