Alright, let’s talk about /proc and /sys. You’ve probably seen these directories sitting there at the root of your filesystem, looking all mysterious and important. They are. But they’re not like other directories. They don’t contain files in the traditional sense. They’re more like magical, on-the-fly generated windows directly into the soul of your running kernel. Think of them as the kernel’s control panel and diagnostic dashboard, all represented through a filesystem interface because, well, “everything is a file” is the Linux mantra, and they really ran with it.

The key thing to remember is that reading from and writing to these “files” is a direct conversation with the kernel. You’re not hitting a disk; you’re calling a function. When you cat /proc/cpuinfo, the kernel is gathering the current data about your CPUs and handing it to you as text. When you echo 1 > /proc/sys/net/ipv4/ip_forward, you’re not changing a byte on a platter, you’re flipping a live switch in the kernel’s networking stack. It’s brilliant, and a little bit absurd, but it works incredibly well.

/proc: The Process Psychic

The /proc filesystem (procfs) is the older of the two, originally designed to expose information about running processes—hence the name. Each running process gets a directory, /proc/<PID>, filled with “files” that tell you everything you’d ever want to know (and a lot you probably don’t) about that process: its memory map, environment variables, open file descriptors, you name it.

But it grew. It grew like a bureaucratic empire, sprouting non-process-related files that expose system-wide information. The most important ones are your friends for life:

# What kind of silicon are we running on? Behold.
cat /proc/cpuinfo

# How much memory does the system have, and how is it being used?
cat /proc/meminfo

# Every kernel module currently loaded into memory.
cat /proc/modules

# A wealth of information about the kernel itself: version, build host, etc.
cat /proc/version

The real power, and danger, lies in the /proc/sys subtree. This is where you can change the kernel’s runtime parameters. The structure mirrors the kernel’s internal sysctl structure. Want to enable IP forwarding? That’s a networking parameter, so you’ll find it under net/ipv4/.

# Check the current state (0 is off, 1 is on)
cat /proc/sys/net/ipv4/ip_forward

# Turn it on. Note: you need root privileges to write to most files here.
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

Pitfall Alert: These changes are live, but they are not persistent. The moment you reboot, they’re gone. This is great for testing, but for anything permanent, you need to use sysctl (which uses these same interfaces under the hood) and add the setting to /etc/sysctl.conf or a file in /etc/sysctl.d/.

/sys: The Hardware Hive

While /proc became a dumping ground for all sorts of kernel state, /sys (sysfs) was created with a more focused goal: to represent the kernel’s unified device model. It’s a hierarchical view of all the devices, buses, and drivers known to the kernel. If /proc is the kernel’s debug console, /sys is its detailed blueprint.

Walking through /sys is a lesson in how your computer is actually wired together. You’ll see directories for the physical buses (pci0000:00/), the devices attached to them, the drivers that control them, and the modules they depend on.

Where this gets incredibly useful is with hotpluggable devices and manipulating device attributes. Need to change the brightness of your screen? On many laptops, that’s a file in /sys/class/backlight/. Want to see the power state of a USB device?

# Find your USB device's path. It'll be under /sys/bus/usb/devices/
# Let's say it's 1-1.3. Check its power state.
cat /sys/bus/usb/devices/1-1.3/power/runtime_status

# It might say 'suspended'. To wake it up, you can often...
echo on > /sys/bus/usb/devices/1-1.3/power/control

Best Practice & Major Pitfall: Be incredibly careful writing to /sys. While /proc/sys mostly contains tuning knobs, /sys contains low-level hardware controls. Writing the wrong thing to the wrong file can absolutely, without warning, hard hang your machine or cause data loss. The kernel trusts you, the root user, to know what you’re doing. It’s a trust-but-verify system where it doesn’t actually verify.

Why Two of Them?

This is the part where we call out the questionable choices. The existence of both /proc and /sys is a classic case of “this is how it started” vs. “this is how we should have designed it from the beginning.” /proc got bloated. It was being used for things far beyond its original purpose. sysfs (/sys) was the correction—a new, cleaner, more structured filesystem for the new use case of exposing the device tree.

The result is a mess of historical baggage. Some system information is in /proc, some is in /sys, and the line isn’t always clear. For example, interrupt information is in /proc/interrupts, but the devices that use those interrupts are detailed in /sys. You just have to learn the landscape. It’s not elegant, but it’s what we have, and it’s powerfully flexible because of its chaos.

So, use /proc for process info and system-wide status and tuning. Use /sys for anything related to the hardware device tree and low-level device control. And remember, you’re not editing files; you’re tweaking the very fabric of your operating system. Now go forth, and don’t accidentally disable your primary hard drive.