ced4568andClaude Sonnet 5
15b616274b
Adds all 6 ROOT 01 modules (how computers run software, the shell, filesystem navigation, files & text, processes, users & permissions foundations), each with a real lesson, demonstration/guided exercise, knowledge check where warranted, a hands-on Lab, and a reflection — 35 activities, 29 new content files. Adds 6 new hands-on Linux scenarios (linux-inspect-hardware, linux-shell-basics, linux-filesystem-navigation, linux-files-and-text, linux-process-management, linux-permissions-foundations) plus 2 MCQ scenarios, using the existing generic scenario/ validation engine (docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §1) — every one tested end-to-end via the real scenario setup/validate API, including negative tests confirming they correctly FAIL when not actually solved (e.g. the process-management scenario fails while the target process is still running; the permissions scenario is tested against a real `su - labuser` denial). Wires rootnode-linux-foundations-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Adds a real, server-side ROOT 01->02->03->04->05 course prerequisite chain (courses.prerequisites) — verified live on two students: one who completed ROOT 01 sees ROOT 02 unlock; a fresh student sees ROOT 02 correctly locked while 03/04/05 stay vacuously satisfied (their own prerequisite courses are still empty). ROOT 06+ and the Capstone are unaffected. Co-Authored-By: Claude Sonnet 5 <[email protected]>
3.4 KiB
Processes
What a process actually is
A process is a running instance of a program — its own code, its own private memory, and a
unique identifier the kernel tracks called a PID (Process ID). Run the same program twice
(open two terminals both running bash), and you get two separate processes with two different
PIDs, even though they're running identical code.
Foreground vs. background
A command you run normally occupies your terminal until it finishes (foreground) — you
can't type anything else until it's done. Append & to run it in the background instead,
freeing your terminal immediately while the process keeps running. sleep 300 & starts a
300-second sleep in the background and hands your prompt right back.
Inspecting processes: ps and top
ps aux— a snapshot of every process currently running, including its PID, how much CPU/ memory it's using, and the exact command that started it.top(orhtop, if installed) — the same idea, but live-updating and sorted by resource usage, useful for "what's actually eating CPU/memory right now."
Stopping a process: kill and signals
kill <PID> doesn't instantly destroy a process — it sends it a signal, a message the
process can (usually) choose how to respond to. The default signal, SIGTERM (15), politely
asks a process to shut down, giving it a chance to clean up first. kill -9 <PID> sends
SIGKILL, which the kernel enforces immediately with no chance for the process to react —
appropriate only when a process is truly stuck and ignoring SIGTERM. kill -0 <PID> is a
special case: it sends NO real signal at all, just checks whether the PID still exists —
exactly how you confirm "did that process actually stop" without side effects.
Process hierarchy
Every process (except the very first one at boot) has a parent — the process that started it. Your shell is the parent of every command you run from it. This matters later: a parent process's own lifecycle can affect its children (this is part of why a container, which is often just one process tree, behaves the way it does when its main process exits).
Why this matters for containers and Kubernetes
A container is, underneath, mostly an isolated process (or small process tree) with its own view of the filesystem and network — when people say "a container exited," they mean its main process exited, exactly the same event you'll cause on purpose in this module's Lab. Kubernetes' entire job, at its core, is deciding which machine a process (inside a container) runs on and restarting it if it dies unexpectedly — none of that will feel intuitive without this module's model of what a process actually is.
Instructor Notes
Lesson goal: Build a real process mental model (PID, foreground/background, signals, parent/child) that ROOT 04 (containers) and ROOT 06 (Kubernetes workloads) both directly build on without re-explaining.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: students often think kill always means "forcefully
destroy" — clarify that plain kill sends a polite, ignorable request (SIGTERM), and -9 is
the forceful escalation, not the default.
Discussion question: "What do you think happens to a container if its main process exits on its own, versus if something outside kills it?" (Don't need a complete answer yet — just plant the question for later.)