Htop

Right, so you’ve got a process running. You can hear its digital heartbeat, sucking up CPU cycles and memory, but you have no idea what its Process ID (PID) is. You could run ps aux | grep and start squinting at a wall of text, hoping you spot the right one. But let’s be honest, that’s what our ancestors did. We have better tools. Enter pgrep and pidof—two commands that exist for the singular, beautiful purpose of turning a process name into its PID, saving you from that grep-induced eyestrain.

Right, so you’ve got a process hogging your CPU. Maybe it’s a runaway script, maybe it’s ffmpeg trying to turn the entire Lord of the Rings trilogy into a single GIF. You don’t necessarily want to kill it; you just want to politely ask it to take its foot off the gas pedal so the rest of your system can breathe. This is where nice and renice come in. They’re your tools for adjusting a process’s priority in the CPU’s scheduling queue.

Right, let’s talk about process assassination. You’ve got a misbehaving program, a script that’s hung, or a service you need to tell to re-read its config files. You don’t just yank the power cord; you send a signal. That’s what kill, killall, and pkill are for. They’re your tools for sending polite (or… less polite) notes to other processes. Think of them as the difference between tapping a colleague on the shoulder and setting their desk on fire.

Right, let’s talk about signals. You’ve probably already used them, even if you didn’t realize it. Hitting Ctrl+C in a terminal to stop a runaway program? That’s you sending a signal. They’re the operating system’s slightly clunky, occasionally infuriating, but utterly essential way of poking a process in the ribs to get its attention. Think of them as administrative inter-process tweets: short, limited to a predefined set of messages, and utterly impossible to ignore.

Alright, let’s pull back the curtain on what your processes are actually doing when your back is turned. You can’t just ps aux and see a list of perfectly well-behaved programs politely taking turns. Oh no. The kernel is a chaotic ballet of processes flitting between states, and if you don’t know the dance steps, you’re going to be hopelessly lost when things go wrong. The classic states—Running, Sleeping, Zombie—are a good start, but the Linux kernel, in its infinite wisdom (and occasional madness), gives us a few more nuanced, and frankly terrifying, letters to play with: R, S, D, Z, and T.

Right, let’s talk about getting a real-time look under the hood of your system. ps is a fantastic snapshot tool, but when your CPU is screaming and your fans sound like a jet engine, you need a live dashboard, not a photograph. That’s where top and its far superior descendant, htop, come in. They’re our interactive process viewers, and they’re about to become your best friends for diagnosing why your machine is suddenly so interested in mining bitcoin (it’s probably a runaway Chrome tab, not an actual cryptominer, but we’ll find out).

Right, let’s talk about ps aux. This is the command you’ll run when you ask yourself, “What in the name of all that is holy is actually running on this machine right now?” It’s the first step in diagnosing everything from “why is my fan screaming” to “why is this server on fire.” It’s a foundational tool, and learning to read its slightly arcane output is a superpower. Let’s break it down because ps aux itself is a bit of a historical mess. The ps command has two major syntax traditions: the BSD style (which is what aux is) and the System V style. Mixing them is a recipe for frustration. The aux flags are a beautiful, if confusing, amalgam: