/proc, /sys & Reading the System Directly

In one line

Tools like top, free, and ps read their data from /proc. Knowing where it comes from lets you inspect any process or kernel setting directly, even on minimal containers with no tools installed.

0/5 · 0%

Think of it like this

A car's dashboard shows speed and fuel, but a mechanic can plug straight into the engine's diagnostic port. /proc and /sys are Linux's diagnostic port: files that aren't on disk at all, generated live by the kernel when you read them.

Key ideas

01
/proc/<pid>/ describes one process: cmdline (how it was started), environ (its environment variables, readable by root/owner), status (state, memory, threads), fd/ (every open file and socket), limits (ulimits), cgroup (which container/cgroup it's in). /proc/self is the process reading it.
02
System-wide: /proc/cpuinfo, /proc/meminfo (what free summarises), /proc/loadavg, /proc/mounts, /proc/net/tcp (sockets), /proc/pressure/{cpu,memory,io} (PSI: how much time tasks are STALLED waiting for a resource, a great saturation signal on modern kernels).
03
/proc/sys/ holds tunable KERNEL PARAMETERS, changed with sysctl: net.core.somaxconn (listen backlog), vm.swappiness, fs.file-max, net.ipv4.ip_local_port_range. Changes are temporary until written to /etc/sysctl.d/*.conf. Kubernetes and Docker expose some of these per pod/container.
04
/sys exposes devices and drivers (disks' queue settings, network interfaces, cgroup controllers under /sys/fs/cgroup). Along with /proc, it's how container runtimes enforce and report limits (Docker course, cgroups).
05
ULIMITS cap per-process resources: ulimit -n (max open files, often 1024 by default, far too low for busy servers, causing 'Too many open files'). For services, set LimitNOFILE= in the systemd unit rather than relying on shell settings.

Code & diagrams

inspect a process without any toolsbash

PID=$(pgrep -f java | head -1)
tr '\0' ' ' < /proc/$PID/cmdline; echo      # exact command line
grep -E 'State|VmRSS|Threads' /proc/$PID/status
ls -l /proc/$PID/fd | wc -l                   # open file descriptors
grep 'open files' /proc/$PID/limits           # the limit it runs with
cat /proc/$PID/cgroup                          # which cgroup / container
cat /proc/pressure/memory                     # some avg10=0.00 ... full avg10=0.00 ...
sysctl net.core.somaxconn                     # a kernel tunable

Explain it without notes

Why does 'Too many open files' happen, and how do you fix it properly for a service?

Practice

A container has no ps, top, or netstat. How do you find what process is listening on port 8080?

Trade-offs

↔
Tuning kernel parameters can fix real bottlenecks (backlogs, file limits) but changing them blindly can hurt stability; change one, measure, and persist it in config management.

Done when you can

I can read a process's state, limits, and open files from /proc
I know where sysctl settings live and how to persist them