/proc, /sys, /dev, /run — the kernel-exposed filesystems

Linux exposes most of its runtime state as files. The four pseudo-filesystems introduced here — /proc, /sys, /dev, /run — are how sysadmins and tools observe and influence the kernel without writing ioctl-based code.

/proc — process and kernel information

/proc is implemented by the kernel directly. There is no on-disk storage. When you read a file under /proc, the kernel synthesises the contents on demand.

Process directories

Every running process has a directory named after its PID:

/proc/1/                ← PID 1 (init)
├── cmdline            ← null-separated argv
├── comm               ← executable basename
├── cwd -> /            ← current working directory (a symlink)
├── environ            ← environment variables
├── exe -> /usr/lib/systemd/systemd
├── fd/                 ← open file descriptors
├── maps               ← memory mappings
├── status             ← process state, VmRSS, threads
├── task/               ← threads (one subdir per TID)
└── limits             ← ulimit values

$ cat /proc/$$/status | head -10

Name:   bash
Umask:  0022
State:  S (sleeping)
Tgid:   12345
Ngid:   0
Pid:    12345
PPid:   12340
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000

Kernel and system information

/proc/version              ← kernel version + build
/proc/cmdline              ← kernel command line from boot
/proc/cpuinfo              ← CPU details (model, cores, flags)
/proc/cgroups              ← cgroup controller list and hierarchy info
/proc/meminfo              ← memory accounting
/proc/loadavg              ← load average (1, 5, 15 minute)
/proc/uptime               ← seconds since boot, idle seconds
/proc/filesystems          ← supported filesystem types
/proc/mounts               ← current mount table (also visible in /etc/mtab)
/proc/sys/                 ← sysctl knobs as files

/sys — devices, drivers, and kernel subsystems

/sys (sysfs) is also implemented by the kernel. It exposes the kernel device model: every device, bus, driver, and class is represented as a directory tree.

/sys/block/                 ← block devices (sda, nvme0n1, …)
/sys/class/                 ← device classes (net, power, thermal, …)
/sys/class/net/eth0/        ← a specific NIC\'s state, speed, statistics
/sys/bus/                   ← registered buses (pci, usb, scsi, …)
/sys/fs/                    ← filesystem-specific knobs
/sys/kernel/                ← kernel-wide settings (debug, security, …)

$ ls /sys/class/net/

eth0
lo

$ cat /sys/class/net/eth0/speed

10000

A common production use: findmnt reads /proc/self/mountinfo and /proc/mounts to report the current mount table.

/dev — device files

/dev exposes device files. Two flavours:

• Block device files (e.g. /dev/sda, /dev/nvme0n1) — represent block-addressable storage. Read and written in fixed-size blocks.
• Character device files (e.g. /dev/null, /dev/tty, /dev/random) — character-stream or pseudo devices.

Modern distributions back /dev with devtmpfs, which is managed by the kernel and udevd. udevd listens to kernel uevents and creates, modifies, or removes device nodes in /dev as hardware comes and goes (drives plugged in, NICs renamed, etc.).

/run — runtime state since boot

/run is tmpfs-backed, lives in memory, and is cleared on reboot. It holds transient state that programs need to communicate with each other across the boot session.

/run/systemd/              ← systemd\'s runtime state
/run/systemd/resolve/      ← systemd-resolved\'s resolver state
/run/dbus/                 ← D-Bus system bus socket
/run/chrony/               ← chronyd drift tracking
/run/sshd/                 ← sshd privilege-separation directory
/run/lock/                 ← lockfiles; /var/lock is a symlink to here

Why a separate /run instead of stuffing everything into /var/run? The split makes it explicit that this data is not preserved across reboots. A /var/run of yesterday does not exist; only /run of today does.

$ findmnt /run

TARGET SOURCE    FSTYPE OPTIONS
/run   tmpfs     tmpfs  rw,nosuid,nodev,size=3254360k,nr_inodes=819200,mode=755

What this lets you do

The four pseudo-filesystems convert kernel state into readable text. That gives you a handful of one-liners that are useful in production:

1. Which process is using this port? ss -tlnp 'sport = :443' prints the PID directly - start there, not in /proc. Once you have the PID, ls -l /proc/<pid>/fd/ | grep socket enumerates every socket that process holds.
2. What is the kernel command line? cat /proc/cmdline — including the crashkernel= reservation, root device, and any systemd.unit= overrides.
3. Is this filesystem mounted? cat /proc/mounts | grep <path> — /etc/mtab is usually a symlink here.
4. What CPU flags does this host expose? grep ^flags /proc/cpuinfo | head -1 — required for AES-NI, AVX, vmx/svm (virtualisation), and so on.
5. Why is /run filling? Use du -sh /run/* to see the breakdown. Usually a stray socket directory or a leftover lockfile

Knowledge check