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

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. The problem nobody explains properly 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. The experiment 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 seeR (running),Z (zombie), andD (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. Why this actually matters 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 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. The bridge to where this series is going 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. Try it yourself Before the next post, try answering these on your own machine (no need to reply here, this one's for you): - Run ps -eo pid,ppid,stat,etime,cmd --forest and visually identify which process is the parent of which. - Find (or fail to find) a process in Z (zombie) state - if you don't find one, that's already useful information: your system is healthy on that front right now. - Compare ps aux withtop (orhtop ) 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. Top comments (0)