You are writing a metrics collector that reads Linux /proc files directly instead of shelling out to tools. Which properties of procfs, as opposed to an ordinary file on disk, does the code have to handle?

## Reading is executing An ordinary read pulls bytes that already exist, possibly from page cache. A procfs read runs kernel code that formats current state into a buffer. Everything unusual about writing a collector follows from this one fact. The first practical consequence is the access pattern. Open the file, read until EOF, close, and do it again next cycle. Keeping a descriptor open and re-reading is fragile: many procfs files are implemented so that content is produced during an iteration starting at open, and lseek-and-reread behaviour is not something to rely on. The cost of the open is small; the cost of being subtly wrong is not. ## Snapshots, not events Everything procfs reports is instantaneous. There is no history, no ring buffer of past values, and no notification when something changes — you cannot watch a procfs file for changes the way inotify works on a real file, because there is no write event to observe. A related trap is the *type* of number you are reading. Most system-wide statistics are cumulative counters since boot: the fields in /proc/stat are jiffies accumulated per CPU state, /proc/net/dev counts bytes and packets since the interface came up, and /proc/diskstats accumulates I/O totals. A collector must store the previous sample and emit a delta over elapsed time to produce a rate, and it must detect the counter going backwards — a reboot, an interface being recreated, or a counter wrapping — and drop that interval rather than emitting an enormous spike. By contrast, /proc/meminfo and /proc/loadavg report levels, which are used as-is. ## Consistency and races There is no snapshot isolation across files, and only weak guarantees within one. Two reads of two different files are two moments in time, so a ratio computed from them is approximate by construction. Within a single large file — a long process list, a big mapping list — the content is produced incrementally as your reads consume it, so a very long listing can be internally inconsistent: an entry added while you were reading may appear, and one removed may vanish. Process enumeration is the sharpest edge. The sequence "list /proc, filter numeric directories, open /proc/<pid>/stat for each" has a window in which the process can exit. The `open()` then fails with ENOENT, and reads on an already-open descriptor for a dead process can fail too. Correct code treats this as an expected, silent outcome. Logging it at error level produces a log line for every short-lived process on the box, which on a build machine is thousands per minute. Worse than a missing PID is a *reused* one. The kernel allocates PIDs increasing until it wraps at the value of `kernel.pid_max`, and on a busy host that wrap happens often. If you enumerate PID 4711, take a sample, and come back a minute later, the 4711 you find may be a different process entirely. Robust collectors capture a distinguishing field alongside the sample — the process start time from /proc/<pid>/stat is the conventional choice — and treat a change in it as "old process gone, new process started" rather than as a wild jump in that process's counters. ## Cost is not uniform Some files are nearly free; others are not. Reading /proc/<pid>/stat or /proc/<pid>/status is a formatted dump of fields the kernel already tracks. Reading /proc/<pid>/smaps requires walking the process's page tables mapping by mapping, and for a large-heap process with thousands of mappings this is measurably expensive — enough that a naive per-second scrape of every process on a dense host burns real CPU and perturbs the very system it is measuring. Where you need only totals, /proc/<pid>/smaps_rollup gives the aggregate at a fraction of the cost (it requires Linux 4.14 or newer). The general discipline is to scrape cheap files often and expensive files rarely, and to be honest that an observer at high frequency is part of the workload. ## Permissions and visibility Your collector will not see everything unless it is privileged. Another user's /proc/<pid>/environ, fd/ and cwd are restricted to that user and root. Beyond that, procfs accepts a `hidepid` mount option that hides other users' process directories outright, so on a hardened host an unprivileged collector may enumerate almost nothing and report a near-empty machine rather than an error. Detect that case explicitly instead of publishing a confidently wrong zero. ## Stability of the format Procfs is text, unversioned, and parsed by an enormous amount of software, so fields are appended rather than reordered — but they *are* appended, and new lines appear in new kernel versions. Parse by field name where the format is `key: value`, and by index only where the layout is genuinely fixed and documented, tolerating extra trailing fields rather than rejecting the line.