Linux: Processes, Threads and signals

What is a process?

https://www.youtube.com/watch?v=4rLW7zg21gI

https://www.youtube.com/watch?v=ls5cGi12kGw&list=PLtK75qxsQaMKLUENMaPlD_O2qS8ZBGjuy

A process is program in execution.

So what is a program ?: A program is an executable program. A program contains code or set of processor instructions which are stored as a file on disk.

CPU has a program counter. Program is loaded into the memory and then program counter tells the CPU which part of the memory to look at, which process it is, what operation is next one.

Active process will also include the resources(CPU, RAM, I/O) program needs to run. These resources are managed by the operating system.

A process will contain below components:

Processor registers
program counters
stack pointers
memory pages

Each process has its own memory space which will contain:

code
data
heap
stack

One process cannot corrupt the memory space of another process.

What is a thread?

A thread is the unit of execution within a process.

Analogically: Building a house is a process, but the people doing the work to install the pipes, paint the walls and do the electrical work are all the working threads within the process of building the house.

if I run chrome, and have 10 tabs open, I will have 10 processes running. Within each process are 1 or many units of work (called threads) responsible for memory management, access, logic, etc.

Process state

A process can be classified into different state’s, depending upon the current status. For example, a process can be idle, waiting for a user input, a process can be waiting for an IO request to be completed, A process can be zombie, or even orphan.

Processes which are not currently doing any task, and are waiting for any interrupt, or say for example a process which is waiting for an input from the user is normally in the interruptible sleep state. This state of a process is denoted by “S”. You will find a large number of processes in the system with an S state. This is because, most of the processes are in the started state, and are waiting for something to execute as required

what is zombie and orphan processes in linux?

All processes that run on a Linux system has a parent process to it.if you have httpd web server running on the system, all other httpd processes will be spawned by a single master httpd process.

In below example, 3385583 is child process of parent 3385582:

manojkumar@n36-186-058:~$ ps aux | grep nginx
root     3385582  0.0  0.0  63536  2744 ?        Ss   Apr04   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 3385583  0.0  0.0  63920  3288 ?        S    Apr04   0:00 nginx: worker process
www-data 3385585  0.0  0.0  63920  3288 ?        S    Apr04   0:00 nginx: worker process

manojkumar@n36-186-058:~$ ps -p 3385583 -o ppid
   PPID
3385582

Zombie process: A zombie process is called a zombie, because, its a dead process without any task left to do(without utilizing any system resource) just sitting in the process table to be reaped by the parent.

when a process completes its execution, it informs its parent process that it has completed its execution. Now after being informed, its the job of the parent to get the complete status of the process that has completed execution, and then finally remove it from the process table, so that the pid is available for reuse. There are some irresponsible parent processes that takes a lot of time to collect the complete status of its children, even after being informed. Due to this reason, the children becomes zombies till the parent does its job of collecting information and removing them from the list.

You cant kill a zombie, because its a dead body, and how will you kill a dead body.you can surely ask the parent process to reap their child processes that have completed execution.

his can be done by sending SIGCHLD, signal to the parent. This SIGCHLD signal will ask the irresponsible parent to reap their children, who are zombies.

orphan process:

Orphan processes are those unfortunate processes whose parents die leaving the children behind. Parents can die due to accident (which means can crash). However some powerful processes immediately adopts the children, whose parents are no more, and are orphan. So for example, systemd adopts almost all orphan process immediately.

In such cases, you will see PID no 1 as their parent process.

Commands:

My processes which are running: use ps command

all processes(by users, cpu etc) which are running: ps aux

active process which are running: top
- There is limit on number of processes which can be run. the limit can be found using:

manojkumar@n36-186-058:~$ cat /proc/sys/kernel/pid_max
4194303

We are seeing 4194303 as our machine is 64-bit.

process tree: pstree

SIGNALS

Explanation for 5 years old:

Alright, imagine you’re playing with your toys, and your mom wants to tell you something. She might use different ways to get your attention. She could tap you on the shoulder, which is like a gentle “Hey, look at me,” or she could use a louder voice to tell you it’s dinner time, which means “Stop playing and come eat.” In the world of computers, especially in Linux, we have a way for the operating system/technically kernel (which is like the mom in this example) to send messages to the programs /technically process(like you playing with toys).

These messages are called “signals.” Signals are like little nudges or notes that the operating system can send to programs to tell them to do something or to let them know about something that has happened. Here are some of the common signals, explained in a simple way:

SIGINT (Signal Interrupt):

Imagine you’re building a block tower, and someone says “Stop!” That’s like SIGINT. It’s a signal that tells a program to stop what it’s doing. You usually send this signal by pressing Ctrl+C on the keyboard when you want to stop a program that’s running in the terminal.

SIGQUIT (Signal Quit):

This is like saying “Quit and show me what you were doing.” It’s like SIGINT, but it also asks the program to create a core dump, which is like a snapshot of what the program was doing when it was told to quit. It’s like if you took a picture of your toys before cleaning them up.

SIGKILL (Signal Kill):

This one is like a parent saying, “I’m not asking, I’m telling. Stop now!” It forces a program to stop immediately. The program can’t ignore this signal or do any cleanup; it just stops. This is used when a program is stuck and won’t stop with the gentler signals.

SIGTERM (Signal Terminate):

This signal is like being told, “Please finish up, it’s time to go.” It’s a polite way of asking a program to stop. The program can do some quick cleaning up (like saving its work) before it stops.

SIGSTOP (Signal Stop):

Imagine you’re in the middle of playing, and someone hits the pause button. You freeze and wait until they hit play again. SIGSTOP is like that pause button; it tells a program to stop and wait. Unlike SIGKILL, this signal doesn’t end the program; it just puts it on hold.

SIGCONT (Signal Continue):

This is like the play button after being paused. It tells a program that was stopped with SIGSTOP to wake up and keep going.

Just like you know that different tones of voice or gestures from your mom mean different things, programs understand what to do when they get these signals. And just like you might clean up your toys when you’re done playing, programs can do certain things when they get signals, like saving their work or saying goodbye before they stop. Signals are a way for the operating system to communicate with programs in a language that they understand.

Signals are sent by the kernel, which is the core part of the operating system. The kernel manages the system’s resources and interacts with the hardware. It acts as a mediator between the software (applications and processes) and the physical components of the computer.

When a signal needs to be sent, it is the kernel that actually delivers the signal to the target process. Signals can be sent for various reasons:

User Actions: When you press keys like Ctrl+C to interrupt a process, the kernel sends the SIGINT signal to the process running in the foreground of your terminal.
Program Requests: One program can ask the kernel to send a signal to another process. For example, when you use the kill command in the terminal, you’re asking the kernel to send a specified signal to a process.
Kernel Events: The kernel itself might need to communicate with processes in response to certain events, like illegal operations (which might trigger a SIGSEGV signal) or hardware exceptions.
System Events: Signals can also be sent due to system-level events, such as the system shutting down, which might send a SIGTERM signal to allow processes to terminate gracefully.

So, while it’s common to say that the “operating system” sends signals, it is technically the kernel that performs this action as part of its role in managing the system.