The Linux Autopsy: 8 Discoveries That Changed How I View Operating Systems

Most developers treat Linux like a black box: you type a command, and magic happens. But after "hunting" through the filesystem, I’ve realized that Linux isn’t a black box at all—it’s a transparent, hyper-organized library where every secret is hidden in plain sight.

In this post, I’m moving past ls and cd. We are going into the "under the hood" files that control networking, process memory, and system DNA. Here are my findings from the deep investigative trail.

---

1. The Matrix of the Kernel: /proc

If you delete everything on your hard drive, /proc it will still be there when you boot. That’s because /proc it doesn't exist on your disk; it exists in your RAM. It is a Virtual Filesystem (VFS).

• What it does: It acts as a real-time portal into the Linux Kernel. It allows you to "read" the state of the CPU, memory, and running processes as if they were simple text files.

• The Discovery: I navigated to /proc/self. This is a magical symbolic link that points to the directory of whichever process is looking at it.

• Why it matters: Inside /proc/[PID]/maps, I found the memory map of a running process. It shows exactly where the executable code (text), the heap, and the stack reside in virtual memory.

• Investigator’s Insight: If a process is "stuck," you can check /proc/[PID]/status to see if it’s in a "Deep Sleep" (Uninterruptible Disk Sleep), which usually points to a hardware failure or a hanging network drive.

To view the information of a specific process assigned a PID.

For a specific process with an assigned PID, you can get the PID of any running process using the ps command.

ps -aux

If we want to check information about the process with PID 300, we can use the following command.

ls -ltr /proc/300

---

2. The Master Switchboard: /etc/nsswitch.conf

We are taught that DNS lives in /etc/resolv.conf. But while hunting, I found the "boss" of resolv.conf: the Name Service Switch.

• What it does: It defines the order of operations for system lookups.

• The Problem it Solves: How does Linux decide whether to check the local /etc/hosts file first or ask a DNS server like 8.8.8.8? This file holds that logic.

• The Insight: I found a line: hosts: files dns. This means the system checks local files first. If I want to "hijack" a domain name for local development without a proxy, I just add it to /etc/hosts. However, if dns came before files, my local overrides would be ignored. It’s the ultimate arbiter of system "truth."

cat /etc/nsswitch.conf

---

3. The Blueprint of Persistence: /etc/fstab

I used to think mounting a drive was a manual task. /etc/fstab (File System Table) proved me wrong.

• What it does: It contains the descriptive information about the various file systems that the system can mount.

• Why it exists: It automates the connection between physical hardware (or remote cloud storage) and the Linux directory tree.

• Interesting Discovery: I noticed that modern Linux uses UUIDs (Universally Unique Identifiers) like UUID=550e8400-e29b... instead of /dev/sda1.

• Why this matters: In the old days, if you plugged your hard drive into a different port, the name changed from sda to sdb, and the system wouldn't boot. UUIDs ensure that the "ID" of the data is what matters, not the physical "plug" it’s connected to.

image source: https://geek-university.com/linux/etc-fstab-file/

---

4. The Digital Paper Trail: /var/log/auth.log

While investigating security, I realized that Linux is an obsessive record-keeper.

• What it does: This file tracks every single "privilege" event on the system.

• The Insight: I opened this file and saw hundreds of Connection closed by authenticating user root messages from IP addresses in countries I’ve never visited.

• The Lesson: This file is the "Black Box" of a flight recorder. It doesn't just show failures; it shows every time someone uses sudo. If a malicious actor gains entry, this is the first file they try to delete, because it contains the fingerprint of their intrusion.

sudo tail /var/log/auth.log

---

5. The Skeleton Key: /etc/skel

Have you ever created a new user and wondered where their default Documents, Downloads, and .bashrc files come from?

• What it does: The "Skeleton" directory.

• How it works: When you run useradd -mLinux doesn't "generate" a home directory; it clones one. It copies everything from /etc/skel into the new user's home.

• The Insight: This is where system administrators enforce "Culture as Code." If you want every new developer in your company to have a specific set of security aliases or a "Welcome" README, you place it in /etc/skel. It is the DNA template for every human interaction with the machine.

ls /etc/skel

---

6. Zero, Null, and Random: The Logical Ghosts of /dev

In /dev, I found files that aren't files, but "devices."

• /dev/null: The "Black Hole." You can write terabytes of data to it, and it vanishes.

• /dev/zero: A literal fountain of zeros.

• /dev/urandom: The source of entropy.

• The Insight: I discovered that /dev/urandom collects "noise" from device drivers and environmental shadows to create random numbers. This is what powers the encryption for your SSH keys and HTTPS traffic. Without this "file" of random noise, digital security would collapse because numbers would be predictable.

ls /dev/

---

7. The Networking Ledger: /proc/net/route

Forget the ip route command for a second. Where does that data actually live?

• The Discovery: Inside /proc/net/route, I found the raw hex-encoded routing table.

• What I Learned: Each line represents a network path. The IP addresses are in "Little Endian" hex format.

• Why it matters: Most people use high-level tools to see their network. But when those tools fail (or aren't installed on a stripped-down Docker container), the investigator knows that the kernel is always exposing the truth in /proc/net. If a packet doesn't know where to go, the answer is in this text file.

cat /proc/net/route

---

8. Volatile State: The /run Filesystem

Finally, I investigated /run, a directory that clears itself every time you flip the power switch.

• What it does: It stores "Runtime" data.

• The Insight: I found .pid files (Process ID files) and .sock files (Unix Domain Sockets).

• Why it solves a problem: In the past, these lived in /var/run, which was on the physical disk. If the system crashed, the .pid files remained, making the system "think" a service was still running when it wasn't. By moving this to a tmpfs (RAM-based) filesystem in /run, Linux ensures that a reboot provides a truly "clean slate."

---

Conclusion: The Investigator's Mindset

After this exercise, I no longer see Linux as a collection of apps. I see it as a state engine.

• Configuration lives in /etc.

• Variable data and logs live in /var.

• The Kernel's brain is exposed in /proc.

• Hardware is mapped in /dev.

The Linux filesystem isn't just a place to store your Desktop folders; it is the source code of the operating system's behavior, laid out in plain text for anyone curious enough to look.

What was your most surprising discovery in the Linux tree? Let’s discuss in the comments.

---