Right, let’s talk about two of the most useful and most misunderstood directories on your system: /proc and /sys. You’ve seen them, you’ve probably been told not to touch them, and you’ve maybe even peeked inside. They look like regular directories, but they’re not. They’re a live, dynamic, and utterly fascinating view into the kernel’s soul. Think of them as the kernel’s debug console and control panel, magically mapped into your filesystem because, well, it was the most clever way the designers could think of to let user-space programs interact with it.

The core concept here is that these aren’t files stored on a disk. When you cat /proc/cpuinfo, the kernel doesn’t go looking for a file on an SSD. It sees that path, recognizes it as a special case, and runs a little chunk of code that generates the CPU information on the fly, formatting it nicely to look like a text file. It’s a brilliant, if slightly unorthodox, API design.

/proc: The Process and Kernel Dump

The older of the two, /proc (short for process), was originally conceived as a way to get information about running processes. Each running process gets a directory (e.g., /proc/1234 for PID 1234) containing pseudo-files that expose everything from its command line (cmdline) to its memory maps (maps). This is how tools like ps and top get their information; they’re just fancy parsers for the /proc filesystem.

But it grew. It became the kitchen sink for all sorts of kernel information and tunables. Let’s get our hands dirty. Want to see why your machine is slow? Check the load average:

cat /proc/loadavg

0.12 0.21 0.15 2/1245 31289

That last number, 31289, is the PID of the most recently created process. See? Useful trivia!

Need to know exactly what kind of CPU you’re dealing with?

cat /proc/cpuinfo | grep "model name"

But here’s where the “questionable choice” part comes in. /proc also became the place to change kernel settings at runtime. This is where you’ll find files like /proc/sys/kernel/pid_max. Want to change the maximum number of PIDs? You can’t just vim that file. You have to use sysctl or echo a value into it, because it’s an interface, not a document.

# Read the current value
cat /proc/sys/kernel/pid_max
# Set it to a new value (until next reboot)
echo 4194303 | sudo tee /proc/sys/kernel/pid_max

This echo-to-change-things method is a classic Unix hack, but it’s a bit, well, weird. It feels like a workaround that became the standard. And that’s precisely why /sys was created.

/sys: A (Slightly) More Organized Kernel Interface

Enter /sys (or sysfs), introduced with the Linux 2.6 kernel. The designers saw the mess /proc had become and tried to create a more structured system specifically for device and driver information and configuration. /sys is a hierarchical view of your system’s device tree.

It’s where you go to find out everything about your hardware. Want to see all your block devices (disks, partitions)?

ls /sys/class/block/

Each of those is a symlink pointing to the actual device in the /sys/devices tree, which shows the painful, explicit hardware layout. The structure is the point. It tells a story about how devices are connected.

One of the most powerful uses of /sys is for dealing with hot-pluggable hardware, like USB devices. When you plug in a USB drive, the kernel doesn’t just create a /dev/sdb device node and call it a day. It populates a whole structure in /sys. And you can manually “echo” values to simulate events. This is deep magic, but incredibly useful for scripting. For instance, you can manually tell the kernel to rescan a SCSI bus to find new disks without rebooting:

# Find your SCSI host adapter (often host0)
echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan

Common Pitfalls and Best Practices

  1. Permissions, Permissions, Permissions: Most of the interesting writable files in /proc and /sys are owned by root:root. You will need sudo to change anything. This is a feature, not a bug. You can brick your system’s usability until the next reboot by setting some of these values incorrectly.
  2. It’s Not Persistent: Changes made by echoing to files in these directories are live, but they are in-memory only. They will vanish on reboot. To make changes permanent, you must add the setting to /etc/sysctl.conf or a file in /etc/sysctl.d/ for /proc/sys changes. For /sys, it’s often handled by udev rules or other system daemons.
  3. The Format is the API: The data you get back from catting a file is the kernel’s API. If the kernel developers change the format, your script that parses it will break. This is why utilities like lsblk are better than parsing /sys/class/block/ by hand—they handle the API for you.
  4. It Feels Like Magic, But It’s Code: Remember, reading these “files” isn’t free. Each read might trigger a kernel function. Don’t write a tight loop that reads /proc/loadavg a million times a second; you’re just pounding the kernel with unnecessary work. Use sensible polling intervals.

So, use them. Explore them. They are your direct line to the kernel. Just remember to be polite—it’s a privilege, not a right.