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]>
65 lines
3.4 KiB
Markdown
65 lines
3.4 KiB
Markdown
# 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` (or `htop`, 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.)
|