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.