A long-running daemon on a Linux host cannot be restarted, and you need to know which config file it opened, what open-file limit it is actually running under, and whether it is leaking descriptors. How does /proc/<pid> answer all three?

## The kernel's own view of a process /proc/<pid> is not a log, a cache or a report written by the process — it is the kernel's live accounting, formatted on read. That is what makes it authoritative during an incident: it cannot be stale, it cannot be lying about what the process intended to do, and it does not require the process to cooperate. Tools such as `lsof` are readers of these same files. Use `/proc/self` when you want the directory of the process doing the reading, and note that a numeric directory vanishes the instant the process exits. ## Which file did it open `/proc/<pid>/fd/` contains one entry per open file descriptor, named by its number, and each is a symlink to the object behind it: ``` $ sudo ls -l /proc/4711/fd lrwx------ 1 svc svc 64 Aug 20 10:02 0 -> /dev/null l-wx------ 1 svc svc 64 Aug 20 10:02 2 -> /var/log/app/stderr.log lr-x------ 1 svc svc 64 Aug 20 10:02 7 -> /etc/app/app.yaml lrwx------ 1 svc svc 64 Aug 20 10:02 9 -> 'socket:[184223]' ``` Three things to read out of this. First, the target is the path the kernel resolves *now*, so if the config was replaced under the running process the symlink still points at the inode it holds — and if the file was deleted, the target is suffixed with ` (deleted)`, which is how you discover a service still holding a removed log file. Second, non-file descriptors show as `socket:[inode]`, `pipe:[inode]` or `anon_inode:...`, so you can tell how much of the count is sockets. Third, `/proc/<pid>/fdinfo/<n>` gives the current file offset and flags for each descriptor. If you only need the working directory or the binary, `cwd` and `exe` are symlinks to them; `exe` still resolves even if the binary was replaced or unlinked by a package upgrade, which is how you catch a service running a version that no longer exists on disk. ## What limit is it actually under `/proc/<pid>/limits` is the entry people forget, and it settles a very common argument: ``` $ cat /proc/4711/limits Limit Soft Limit Hard Limit Units Max open files 1024 524288 files Max processes 31234 31234 processes ``` Resource limits are per-process and inherited from whatever started the process. A daemon launched by the service manager at boot has the limits its unit configuration gave it, not the limits your interactive login session has, and not whatever you edited in a limits configuration file afterwards — those apply to new sessions. So `ulimit -n` in your shell is evidence about your shell only, and a service that still hits "too many open files" after a limits change is usually a process that was never restarted to pick it up. Reading its /proc entry ends the debate in one command. ## Is it leaking The count of entries in `fd/` is the process's current open-descriptor total. A single sample tells you how close it is to the soft limit; a series of samples tells you whether it is leaking: ``` $ for i in 1 2 3; do ls /proc/4711/fd | wc -l; sleep 60; done ``` A number that climbs monotonically under steady load, and never falls after work completes, is the signature of descriptors that are opened and never closed. Grouping by target — how many are sockets, how many are the same file opened repeatedly — usually names the culprit immediately: repeated opens of one config or certificate file point at a reload path that never closes, and a growing pile of sockets points at connections that are never closed or at a client pool without an upper bound. ## The rest of the directory, and its limits `cmdline` holds the exact argv the process was exec'd with, NUL-separated, so `tr '\0' '\n' < /proc/4711/cmdline` renders it readably; this is more trustworthy than a wrapper script or a unit file, because it is what actually ran. `environ` holds the environment as of exec — it is a snapshot, not live, so variables changed inside the process are not reflected. `status` gives the human-readable summary including UIDs, GIDs, thread count and memory figures; `task/` holds one subdirectory per thread. Two access caveats. Reading another user's `environ`, `fd/` or `cwd` requires being root or the same user, because those entries can contain secrets. And the proc filesystem supports a `hidepid` mount option that restricts which processes' directories a user can see at all; on a hardened host you may need to be root even to list a process directory that would normally be world-visible.