Writing a tiny htop clone in 15 lines of bash
The lightning-fast system monitor htop doesn't use a magical binary API—it simply parses plain text files from Linux's in-memory pseudo-filesystem.
By Poppy Lin
Sparked by Explanation of everything you can see in htop/top on Linux (2019) · discussion
Yesterday I was reading a Hacker News thread discussing a deep-dive guide on htop. A friend had just mentioned using htop because their laptop was getting slow, and the combination made me realize that I didn’t actually understand how the tool gets its live process data!
When you look at htop, it's incredibly fast. It is constantly painting the screen with hundreds of moving bars, updating memory stats, and shifting processes around. I always assumed there must be a special, highly optimized kernel API for monitoring running programs—maybe a streaming socket or a binary interface that pushes state changes directly to the UI.
To figure this out, we could hypothetically run strace to watch the program interact with the operating system in real time.
Executing strace -e openat htop > /dev/null in this thought experiment would reveal every file the tool tries to open. (Redirecting to /dev/null would throw away the actual visual UI output so the raw logs wouldn't completely garble the terminal with colors and grids).
Here is the block of raw output that would immediately pop out:
openat(AT_FDCWD, "/proc/1/stat", O_RDONLY) = 4
openat(AT_FDCWD, "/proc/1/statm", O_RDONLY) = 4
openat(AT_FDCWD, "/proc/2/stat", O_RDONLY) = 4
openat(AT_FDCWD, "/proc/2/statm", O_RDONLY) = 4
It's literally just reading text files!
htop doesn't use a magical binary streaming API at all—it just rapidly loops through the /proc directory, opens /proc/[pid]/stat for every single running process, and parses the plain text inside. (I actually originally thought I understood how tools like this worked but I TOTALLY DIDN'T.) The kernel loves you and wants you to not have to wait, so /proc is incredibly fast to read from since it's just an in-memory pseudo-filesystem. Everything in Linux really is a file!
I was originally going to add memory usage to my little bash script, but I'll be honest: I was looking at the htop manual, and I still don't totally understand the practical difference between RES (resident) and SHR (shared) memory limits. (how does calculating shared pages WORK??) I'm definitely not gonna try to explain Linux memory management today, but if you have a good mental model for it, I would REALLY REALLY LOVE TO KNOW. Please tell me on Mastodon!