Read Process Memory and State from /proc/<pid>/status

You will inspect a running Linux process through /proc/<pid>/status, extract useful fields for a diagnosis, and avoid treating one memory number as a complete accounting. Allow about ten minutes for a first inspection. You need a shell and a process ID. Reading your own process is normally unprivileged; another user's process may be restricted by the host's procfs permissions or mount options.

1. Confirm the local interface

This guide follows the installed proc_pid_status(5) manual from the Debian manpages package, version 6.7-2, on a Linux 6.8 kernel. The file is a kernel-generated view, not a configuration file to edit. Its exact values change as the process runs, and newer kernels can expose additional fields. Use the field meanings documented by your local manual when writing portable tooling.

$ man proc_pid_status
$ dpkg-query -W -f='${Package} ${Version}\n' manpages
manpages 6.7-2

Checkpoint: the manual is available and the package version is recorded. If man reports that the page is missing, stop here and use the documentation installed for your distribution rather than assuming another release has identical fields.

2. Read your own status file

The shell expands $$ to its own process ID. That makes this a safe first test because it does not require you to guess a PID or inspect another user's process.

$ sed -n '1,45p' /proc/$$/status
Name:	bash
State:	S (sleeping)
Pid:	12345
PPid:	12001
VmSize:	...
VmRSS:	...
Threads:	1

The numbers in this example are illustrative and will differ. The file is line-oriented: each record has a field name, a colon, and a value. Memory sizes in the documented Vm and Rss fields are reported in kB. Do not parse the whitespace by assuming one exact number of tabs.

Checkpoint: confirm that the path exists and contains a Pid: line. A process can exit between choosing its PID and opening the file, so a missing file is often a normal race rather than a permissions problem.

3. Select fields for a quick diagnosis

Use awk to keep the output readable when you are checking a service repeatedly. This command extracts identity, state, memory, thread count and scheduler counters without changing the process.

$ awk '/^(Name|State|Pid|PPid|Uid|Gid|VmSize|VmRSS|RssAnon|RssFile|RssShmem|VmSwap|Threads|Cpus_allowed_list|voluntary_ctxt_switches|nonvoluntary_ctxt_switches):/ { print }' /proc/$$/status
Name:	bash
State:	S (sleeping)
Pid:	12345
PPid:	12001
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
VmSize:	...
VmRSS:	...
RssAnon:	...
RssFile:	...
RssShmem:	...
VmSwap:	...
Threads:	1
Cpus_allowed_list:	0-7
voluntary_ctxt_switches:	...
nonvoluntary_ctxt_switches:	...

The state code is more useful than a bare number. The manual defines R as running, S as sleeping, D as disk sleep, T as stopped, t as tracing stop, Z as zombie, and X as dead. A sleeping process is not automatically unhealthy; many idle services spend most of their time waiting.

4. Read the memory fields correctly

VmSize is virtual memory size. It includes address space that may not currently occupy physical RAM. VmRSS is resident set size, while the documented split is RssAnon for resident anonymous memory, RssFile for resident file mappings, and RssShmem for resident shared memory. The manual says the RSS value is the sum of those three fields, but also warns that these values are inaccurate and points to /proc/<pid>/statm for the reason.

Use these values as a quick signal, not as billing-grade accounting. A large VmSize does not by itself prove that a process is using the same amount of RAM. A growing VmRSS deserves a time series and a check against the service's workload. VmSwap covers swapped anonymous private pages, but does not include shmem swap usage according to the manual.

$ awk -F '\\s+' '/^(VmSize|VmRSS|RssAnon|RssFile|RssShmem|VmSwap):/ { print $1, $2, $3 }' /proc/$$/status
VmSize: 131168 kB
VmRSS: 13484 kB
RssAnon: 10264 kB
RssFile: 3220 kB
RssShmem: 0 kB
VmSwap: 0 kB

The values above are shaped like the manual's example, not promised results for your shell. If you need a reliable memory profile, use a tool designed for that measurement and compare observations taken at consistent points in the workload.

5. Check identity and namespaces before acting

Uid and Gid each contain real, effective, saved-set and filesystem IDs. PPid is the parent PID, while Tgid is the thread group ID. For a multithreaded program, Pid identifies the thread represented by this status file, and Threads reports the number of threads in the containing process.

Containers and other PID namespaces make raw PIDs easy to misread. NStgid, NSpid, NSpgid and NSsid show the corresponding identifiers in each PID namespace, ordered from the procfs view outwards into nested namespaces. Compare the namespace visible to the observer with the namespace used by the service before sending a signal or attaching a debugger.

Checkpoint: record the command, the PID, the timestamp and the namespace context with any incident note. Never kill a process merely because a number looks unfamiliar. If you need to stop or restart a service, use its service manager and its documented recovery procedure.

6. Inspect security and scheduling signals

The lower part of the file includes hexadecimal pending, blocked, ignored and caught signal masks. Capability fields such as CapEff and CapBnd are hexadecimal masks, not human-readable lists. NoNewPrivs reports the process bit, and Seccomp reports disabled, strict or filter mode when the kernel includes seccomp support. These fields are evidence for diagnosis, not instructions to weaken a sandbox.

Cpus_allowed_list shows the CPUs on which the process may run. Mems_allowed_list shows allowed memory nodes. The voluntary and nonvoluntary context-switch counters can help explain scheduling behaviour, but a single sample says little. Capture several samples while the problem is present and correlate them with service logs and system-level measurements.

7. Handle failures without changing state

If /proc/<pid>/status is absent, first check that the process still exists and that the PID belongs to the namespace where you are looking:

$ test -r /proc/12345/status && echo readable || echo 'missing or not readable'
$ ps -p 12345 -o pid=,ppid=,comm=,stat=
 12345 12001 example S

Replace 12345 with a PID you have verified. If the process has exited, retry against a live PID. If access is denied, follow the host's least-privilege procedure and do not make procfs broadly readable just to simplify monitoring. Reading a status file does not require elevated privileges for your own process.

Do not write to this path, delete anything under /proc, or treat it as persistent configuration. There is no undo step because the commands in this guide only read kernel-generated data. A shell pipeline can still produce a partial result when a process exits mid-read, so repeat the sample before drawing a conclusion.