What a Process Actually Is

In one line

A process is a running instance of a program, with its own memory, its own process ID, and a parent that spawned it — understanding this model demystifies almost everything else in this phase.

0/4 · 0%

Think of it like this

A recipe (the PROGRAM — a static file sitting on disk, doing nothing by itself) versus someone actually cooking it right now (the PROCESS — a live, running instance, using real resources, that can be paused, watched, or stopped). You can have the same recipe being cooked by five different people simultaneously — five processes from one program.

Key ideas

01
Every process has a unique PID (process ID) assigned by the kernel when it starts, and a PPID (parent process ID) — the PID of whatever process CREATED it. Nearly everything traces back to one process near the very top of this parent-child tree, often called init or systemd (PID 1) on modern systems.
02
A new process is created via FORK (the parent process is duplicated, creating a near-identical child) followed by EXEC (the child then replaces itself with the actual new program to run) — this two-step fork-then-exec dance is how virtually every process on a Unix-like system comes into existence, including every command you type in a shell.
03
A process has several possible STATES: running (actively executing on a CPU right now), sleeping (waiting for something — input, a timer, a lock — genuinely most processes spend most of their life here), stopped (paused, usually by a signal), and zombie (finished, but its exit status hasn't been collected yet by its parent — usually transient, but a persistent pile of zombies indicates a parent that's failing to clean up after its children).
04
Every process also has an EXIT CODE when it finishes — 0 conventionally means success, any non-zero value means some kind of failure (the specific number's meaning is defined by whatever program set it). echo $? immediately after running a command shows the exit code of the command that JUST finished — genuinely essential for scripting (Phase 6 relies on this constantly).

In your stack

→
Running java -jar app.jar starts a process whose PID you can find with ps aux | grep java — and critically, the JVM itself is just ONE process, regardless of how many threads your Spring Boot app spins up internally; threads share the same process's memory and PID, which matters when reasoning about resource limits (Phase 8 covers this).

Code & diagrams

ForkExecdiagram

Every process on the system, including every command you type in a shell, comes into existence this way.

Rendering diagram…

process-basics.shmarkdown

Explore live process info on any Linux machine — entirely read-only.

# Start a background process and note its PID
sleep 300 &
echo "Started with PID: $!"    # $! is the PID of the last backgrounded command

# See it in the process list
ps aux | grep sleep

# Check its parent
ps -o pid,ppid,cmd -p $!

# Check the exit code of the last command
true
echo $?    # -> 0 (success)
false
echo $?    # -> 1 (failure)

# Clean up the background sleep
kill %1

Explain it without notes

What's the practical difference between a program and a process, using the recipe analogy or your own words?

Why does 'fork, then exec' need to be two separate steps, rather than one step that just directly creates and runs a new program?

Practice

Start any long-running command in the background with &, find its PID with ps aux | grep, then check its exit code behavior by killing it and observing what $? reports.

Run a command that's guaranteed to fail (like ls /nonexistent-directory) immediately followed by echo $?, and note the specific non-zero exit code it reports.

Trade-offs

↔
The fork-then-exec model is elegant and has worked for decades, but forking a very large parent process (copying all its memory pages, even if 'copy-on-write' makes this cheaper than it sounds) can be measurably slower than a lighter-weight alternative — which is exactly why long-running server processes that need to spawn MANY children quickly (like a busy web server) often use pooling strategies rather than forking fresh for every single request.

Done when you can

I understand the difference between a program (static, on disk) and a process (a live running instance).
I can find a process's PID and PPID and explain what the parent-child relationship means.
I know how to check a command's exit code with $? and that 0 means success.

Command Palette