If you are learning Linux or DevOps, understanding processes is non-negotiable. Processes are the heartbeat of any operating system. This article explains them in a way that even a teenager could follow, and you can reference it later as you go deeper.

What exactly is a process?

A process is simply a program that is running. When you launch an app, Linux:

loads it into memory,
gives it CPU time,
assigns it a unique ID (PID),
and tracks everything about it (owner, resources, status).

Think of a process as a worker in a factory:

The factory (Linux) gives them tools (CPU, memory).
The manager (kernel) monitors what they are doing.
When they are done, the tools are given back for others to use.

The kernel — the manager of all processes

The kernel is the “boss” that keeps every process in line. It knows:

What state the process is in.
How much CPU/memory it gets.
Who owns it.
What to do if it misbehaves (signals).

When a process ends, the kernel reclaims its resources so others can use them.

How processes are created — fork() and exec()

Processes in Linux are like a family tree: every process is born from another.

fork(): Cloning a Process
1. Linux copies an existing process.
2. The clone is almost identical, but gets a new Process ID (PID).
exec(): Changing Its Instructions
1. After cloning, Linux can swap the program running inside the process.
2. The process stays the same, but now it runs different code.

Analogy:

A parent (shell) photocopies itself → that’s fork().
The child throws away its old script and starts reading a new one → that’s exec().

Visual: fork() and exec()

[ Parent Process ]
        |
        | fork()
        v
[ Child Process (copy) ]
        |
        | exec()
        v
[ New Program running in Child ]

The very first process — init (PID 1)

When Linux boots, the kernel creates one special process called init.

PID = 1
Runs with root privileges.
Starts all other processes — the “mother of all processes”.
It can’t be killed unless the system shuts down.

Visual: init spawning processes

         [ init (PID 1) ]
         /      |      \
       PID 2  PID 3   PID 4
        |       |       |
      ...     ...     ...

💡 Key point: Every process has a parent — except init.

How processes end — termination

A process stops when:

It finishes its job naturally and tells the kernel, “I’m done”.
It is told to stop using a signal (more below).
Its parent process acknowledges it via a wait call (so Linux knows it exited cleanly).

Special cases:

Orphan process: parent dies first → kernel hands it to init (PID 1).
Zombie process: process finished but parent didn’t check on it → remains listed in process table until “reaped.”

Signals — how Linux talks to processes

Signals are notifications sent to processes.

User can press Ctrl-C → sends SIGINT (interrupt).
Kernel can send SIGKILL if something goes wrong.
Programs can even send signals to each other.

What a process can do with a signal:

Ignore it
Handle it in a custom way (save files, cleanup)
Block it temporarily
Die immediately (if it’s SIGKILL, which can’t be ignored)

Common signals you’ll meet:

SIGHUP (1): terminal hung up
SIGINT (2): graceful stop (Ctrl-C)
SIGTERM (15): polite “please exit”
SIGKILL (9): immediate kill — no cleanup
SIGSTOP: pause without killing

kill command — manually sending signals

You can manually tell processes to stop using kill:

kill → sends SIGTERM by default (polite stop).
kill -9 → sends SIGKILL (force kill).

Key differences:

SIGTERM lets the process clean up.
SIGKILL just destroys it instantly.
SIGSTOP suspends it instead of ending it.

/proc filesystem — Linux’s process dashboard

Linux treats everything as a file — even running processes!

/proc holds folders named by each PID.
Inside, you will find details like memory use, CPU stats, and status.
Example: /proc/12345/status → detailed info about process 12345.

Think of it as: peeking inside the kernel’s notebook where it keeps live records of every worker (process).

Job control — multitasking in one terminal

You don’t always need multiple terminal windows to run many tasks. Linux lets you suspend, resume, and switch tasks easily:

Add & after a command → run it in the background.
Press Ctrl-Z → suspend a running task.
Type bg → resume a suspended job in the background.
Type fg %1 → bring job #1 back to the foreground.
Use jobs → list all jobs and IDs.
Use kill %1 → stop job #1 using its job ID.

Visual: Job Control

Terminal:
> long_task &     # run in background
> short_task      # runs in foreground

Ctrl-Z -> suspend foreground
bg     -> resume in background
fg %1  -> bring job #1 to foreground

Why it’s useful: You can run a long process and still type other commands in the same terminal.

Niceness — deciding who gets CPU time first

Linux switches between running processes so quickly that it feels like everything is happening at once. However, each process receives tiny turns on the CPU, called time slices, in a fair, round-robin manner.

What is niceness?

A value that tells Linux how polite a process should be about sharing CPU time.
High niceness (+5, +10): “I’m polite, let others go first.”
Low or negative niceness (-5, -10): “I’m greedy, give me CPU now.”

How to check niceness:

Run top → Look for the NI column.

How to set niceness:

Niceness isn’t just for system updates — it can apply to any process on Linux.

- When starting a program:
  
  bash nice -n 5 your_program
  
  Example:
  nice -n 5 node server.js→ runs your script with lower CPU priority (being “nice” to other programs).
  
  * For a program that’s already running:
  
  bash renice 10 -p <PID>
  
  Example:
  renice 10 -p 3245 → adjusts the priority of whatever process has PID 3245 — could be an update, a browser, or even a game.
  - Visual: Niceness
```
  Process A: nice -n -5   (high priority, greedy)
  Process B: nice -n 10   (low priority, polite)
  Process C: nice -n 0    (default priority)

  CPU slices are shared based on these values
```
    💡Niceness simply tells the kernel who should get CPU time first — and you can control it for any process you start or one that’s already running.

Summary

Processes are just programs running — managed by the kernel.
Every process has a parent — except init (PID 1).
fork() makes a copy, exec() changes what it runs.
Signals are how Linux says “stop,” “pause,” or “clean up.”
The /proc folder is your real-time process dashboard.
Job control helps you multitask without new terminals.
Niceness lets you influence process CPU priority politely.

Understanding how Linux manages processes isn’t just “theory”, it’s the foundation of DevOps. When you know how programs are created, scheduled, paused, or terminated, you gain real control over your systems instead of relying on guesswork.

This article is part of my DevOps Journey — where I learn and share the building blocks of becoming a better DevOps engineer, one step at a time.

Linux Processes — A Beginner-Friendly Guide (for DevOps learners)