{"slug": "linux-from-zero-2-processes-what-s-actually-running-under-your-terminal", "title": "Linux from Zero #2 Processes: what's actually running under your terminal", "summary": "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.", "body_md": "*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.*\n\nHave you ever run `ps aux`\n\nand 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.\n\nOpen two terminals side by side. In the first one, run:\n\n```\nsleep 300 &\n```\n\nThis creates a process that just \"sleeps\" for 300 seconds — doing nothing useful, on purpose, so it can be our test subject.\n\nIn the second terminal, run:\n\n```\nps -eo pid,ppid,stat,etime,cmd | grep sleep\n```\n\nYou'll see a line similar to this:\n\n```\n  PID   PPID STAT     ELAPSED CMD\n12345   9876 S           0:03 sleep 300\n```\n\nNow the question that actually matters: **what is each of these columns telling you about this process's life?**\n\n`PID`\n\n— the unique identity of this process for as long as it exists.`PPID`\n\n— who created this process (the parent process). In your case, probably the shell in your first terminal.`STAT`\n\n— the current state. `S`\n\nmeans \"sleeping\" (interruptible). You'll see `R`\n\n(running), `Z`\n\n(zombie), and `D`\n\n(uninterruptible I/O wait) in other contexts — each one tells a different story about what is or isn't blocking the system.`ETIME`\n\n— how long it's been alive.In production, nobody runs `sleep`\n\non 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`\n\nstate (uninterruptible sleep) for a long time, for example, is almost always a symptom of a disk or storage problem — not an application bug.\n\nNow try killing the process through its parent, not the `sleep`\n\nitself:\n\n```\nkill -TERM <your_shell_PPID>\n```\n\n**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`\n\nchild too (or it gets \"adopted\" by `init`\n\n/`systemd`\n\n, 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.\n\nThis 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`\n\nand `namespaces`\n\na couple of posts from now.\n\nBefore the next post, try answering these on your own machine (no need to reply here, this one's for you):\n\n`ps -eo pid,ppid,stat,etime,cmd --forest`\n\nand visually identify which process is the parent of which.`Z`\n\n(zombie) state — if you don't find one, that's already useful information: your system is healthy on that front right now.`ps aux`\n\nwith `top`\n\n(or `htop`\n\n) 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\".*\n\n*Full track (free, in Portuguese): github.com/roger-oliveira86/kubernetes-do-zero-ptbr*\n\nHave you ever run into a process stuck in `D`\n\nstate 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.", "url": "https://wpnews.pro/news/linux-from-zero-2-processes-what-s-actually-running-under-your-terminal", "canonical_source": "https://dev.to/rogeroliveira86/linux-from-zero-2-processes-whats-actually-running-under-your-terminal-1a0f", "published_at": "2026-08-21 19:40:58+00:00", "updated_at": "2026-08-21 20:15:27.282107+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Linux", "Kubernetes", "systemd", "init", "ps", "sleep", "htop", "top"], "alternates": {"html": "https://wpnews.pro/news/linux-from-zero-2-processes-what-s-actually-running-under-your-terminal", "markdown": "https://wpnews.pro/news/linux-from-zero-2-processes-what-s-actually-running-under-your-terminal.md", "text": "https://wpnews.pro/news/linux-from-zero-2-processes-what-s-actually-running-under-your-terminal.txt", "jsonld": "https://wpnews.pro/news/linux-from-zero-2-processes-what-s-actually-running-under-your-terminal.jsonld"}}