procfs

procfs, usually called the /proc filesystem, is a virtual filesystem generated by the Linux kernel on demand that presents information about running processes and kernel state as ordinary-looking files and directories. In Linux monitoring it is the primary data source behind tools such as top, htop, free, vmstat, ps and lsof, which mostly read and format text from /proc.

Nothing under /proc is stored on disk. Each read triggers kernel code that formats current values at that instant, which is why most files report a size of zero yet return content. A small subset of entries, mainly under /proc/sys, is also writable and changes kernel behavior at run time.

How procfs exposes kernel data in Linux

procfs works by registering callback functions in the kernel for each file. When a program opens and reads /proc/meminfo, the kernel walks its memory accounting structures and prints the result as text into the reader’s buffer. There is no cache of the file contents; two reads a second apart can return different values.

The filesystem is mounted at boot, normally with mount -t proc proc /proc, and systemd or the init system handles this automatically. Mount options such as hidepid=invisible and gid control whether users can see each other’s processes, an important privacy setting on multi-user and shared hosting systems.

Because the data is plain text, procfs follows the Unix tradition that everything can be inspected with cat, grep and awk. The trade-off is parsing cost and format stability: field layouts are part of the kernel’s user-space interface and change rarely, but tools must still handle additions carefully.

Key files and directories under /proc

The /proc filesystem contains system-wide files at the top level and one numbered directory per process. The table lists the entries monitoring work relies on most.

Many system counters are cumulative since boot. CPU time in /proc/stat is measured in clock ticks, usually 100 per second (USER_HZ), so a tool must sample twice and compute the difference to report a percentage. A single read of these files says nothing about current utilization.

Per-process information in /proc/PID

Every process has a directory named after its process ID, plus /proc/self as a shortcut to the reading process. Threads appear under /proc/PID/task/. These directories are how ps, top and lsof learn what each process is doing.

Access to sensitive entries such as environ, fd and mem is restricted by ptrace access mode checks, so ordinary users cannot read another user’s environment. Environment variables can still hold secrets, so passing credentials through the environment remains a risk for any process with sufficient privilege to read them.

procfs compared with sysfs and other interfaces

procfs is one of several kernel interfaces, and newer data often lives elsewhere. Device and driver information moved to sysfs, while high-frequency tracing uses dedicated mechanisms.

The ss utility, for example, reads socket data through Netlink rather than /proc/net/tcp, because parsing the text file becomes slow on servers with hundreds of thousands of connections. The general rule is that procfs is ideal for periodic sampling, while event tracing belongs to strace or eBPF.

Kernel tuning through /proc/sys

The /proc/sys tree holds writable kernel parameters, the same values the sysctl command manages. Writing 1 to /proc/sys/net/ipv4/ip_forward enables routing immediately, and the change is equivalent to sysctl -w net.ipv4.ip_forward=1.

• Runtime changes are lost at reboot unless saved in /etc/sysctl.d/*.conf.
• Typical tunables include vm.swappiness, fs.file-max and net.core.somaxconn.
• Writing requires root or the CAP_SYS_ADMIN capability for most entries.
• Inside containers, much of /proc/sys is mounted read-only for isolation.

Pitfalls when reading procfs

Most errors with procfs come from interpreting values incorrectly rather than from reading them. Common traps include treating MemFree as available memory, when MemAvailable is the correct estimate, and reading cumulative counters as rates.

Processes can also exit between listing /proc and opening a PID directory, so robust tools must tolerate files disappearing mid-read. In containers, many files still reflect the host kernel; /proc/meminfo shows host memory unless a helper such as LXCFS virtualizes it, which misleads applications that size their caches from it.

Put simply

The Linux kernel knows everything about what the computer is doing: which programs are running, how much memory is in use and how busy the processor is. procfs is a window that shows this knowledge as simple text files. Opening one of these files is like asking the kernel a question and receiving a fresh answer on the spot.

The files are not stored anywhere. They are created at the moment someone reads them, which is why monitoring programs can always show current information.

In practice

A system administrator receives an alert that a Java service on a database host fails with too many open files. Instead of restarting it, the administrator finds the PID and runs ls /proc/PID/fd | wc -l, which shows about 65,000 open descriptors. Reading /proc/PID/limits confirms that the soft limit is 65,536.

Listing the fd links shows that most point to sockets, and a quick check of connection states reveals thousands of connections never closed by the application. The root cause is a connection leak, not an undersized limit. The team raises the limit temporarily in the service unit as a stopgap while developers fix the connection pool, and adds a monitoring check that tracks the descriptor count from /proc every minute.