Linux from Zero #2 Processes: what's actually running under your terminal

A developer's blog series 'Linux from Zero' explains how to interpret the output of the `ps` command to understand process states and parent-child relationships. The post uses a `sleep` process as an example to illustrate PID, PPID, STAT, and ETIME columns, and discusses how process states like 'D' (uninterruptible sleep) can indicate storage problems. It also touches on how process isolation relates to containers and Kubernetes.

Part 2 of the "Linux from Zero" series. If you haven't read 1 yet, it's on Medium and DEV.to — start there to understand the approach: investigate through evidence, not by memorizing commands. Have you ever run ps aux and watched a huge list of lines scroll by, without really knowing what to do with it? Most tutorials teach you the command, but not how to think about what it returns. This post is about exactly that: turning a list of numbers into reasoning about what your machine is actually doing. Open two terminals side by side. In the first one, run: sleep 300 & This creates a process that just "sleeps" for 300 seconds — doing nothing useful, on purpose, so it can be our test subject. In the second terminal, run: ps -eo pid,ppid,stat,etime,cmd | grep sleep You'll see a line similar to this: PID PPID STAT ELAPSED CMD 12345 9876 S 0:03 sleep 300 Now the question that actually matters: what is each of these columns telling you about this process's life? PID — the unique identity of this process for as long as it exists. PPID — who created this process the parent process . In your case, probably the shell in your first terminal. STAT — the current state. S means "sleeping" interruptible . You'll see R running , Z zombie , and D uninterruptible I/O wait in other contexts — each one tells a different story about what is or isn't blocking the system. ETIME — how long it's been alive.In production, nobody runs sleep on purpose — but every performance incident I've ever investigated started with exactly this question: "which processes are running, who's the parent of what, and what state are they stuck in?". A process stuck in D state uninterruptible sleep for a long time, for example, is almost always a symptom of a disk or storage problem — not an application bug. Now try killing the process through its parent, not the sleep itself: kill -TERM <your shell PPID Don't actually run this in your main terminal — it's just so you can mentally picture what would happen: killing the parent process usually kills the sleep child too or it gets "adopted" by init / systemd , depending on the system . This reparenting behavior is the same logic behind why, when a container dies unexpectedly, the processes it was hosting disappear along with it. This parent/child relationship between processes is exactly what Linux uses as the foundation for isolating processes into namespaces — the mechanism that, later in this series, becomes containers, and that Kubernetes orchestrates at scale. Understanding processes today, without rushing, is what makes the "aha" moment happen when you get to cgroups and namespaces a couple of posts from now. Before the next post, try answering these on your own machine no need to reply here, this one's for you : ps -eo pid,ppid,stat,etime,cmd --forest and visually identify which process is the parent of which. Z zombie state — if you don't find one, that's already useful information: your system is healthy on that front right now. ps aux with top or htop running at the same time — what changes between a static snapshot and a continuous view? Next in the series: namespaces, and what actually isolates one process from another — the foundation of everything we now call a "container". Full track free, in Portuguese : github.com/roger-oliveira86/kubernetes-do-zero-ptbr Have you ever run into a process stuck in D state during a real incident? What caused it? I'm collecting real-world examples for the next posts in this series — drop them in the comments.