Read Linux Process and System State Through /proc

You will finish with a small set of read-only commands for inspecting processes, threads and system state through /proc, plus a safe way to reason about the privacy-related hidepid mount option. These examples follow the locally installed proc(5) manpage from the Debian manpages package, version 6.7-2. The queued procfs(5) name is an alias for the same proc filesystem documentation.

Allow about fifteen minutes. You need a shell. Ordinary inspection does not need elevated privileges on a normally mounted proc filesystem. Do not remount /proc on a live host just to try an example: mount changes can hide process information from monitoring, diagnostics or other services.

1. Confirm what is mounted

Start by checking that the path is a proc filesystem and record its current options:

$ findmnt -no TARGET,FSTYPE,OPTIONS /proc
/proc proc rw,relatime

Your options may differ. The useful parts are the target, proc filesystem type and any privacy option such as hidepid=1 or hidepid=2. If findmnt reports no result, inspect the mount setup before assuming that individual files are missing. The manpage describes /proc as commonly mounted automatically, but it can also be mounted manually.

2. Use the process links instead of hard-coding a PID

/proc/self resolves to the process that accesses the link. /proc/thread-self resolves to that process's current thread directory. Ask the shell to resolve both:

$ readlink /proc/self
540446
$ readlink /proc/thread-self
540446/task/540446

The numbers are examples from one process and will change on your machine. A common distraction is treating the first number as a stable identifier. It is only the PID of the process doing that particular read. A program that opens /proc/self sees itself, not the shell that launched it.

For a stable reference during one shell session, save the shell's PID and use it explicitly:

pid=$$
printf 'shell PID: %s\\n' "$pid"
readlink "/proc/$pid"
cat "/proc/$pid/status" | sed -n '1,8p'

Expected output includes a numeric PID followed by the first fields of status, such as Name, Umask and State. The exact fields and values belong to the running kernel and process.

3. Inspect process and thread directories

A numeric directory such as /proc/1234 describes the process with PID 1234. The task directory underneath it contains one numeric directory per thread, using the thread ID:

pid=$$
printf 'process: %s\\n' "$pid"
ls -ld "/proc/$pid" "/proc/$pid/task"
printf 'threads:\\n'
find "/proc/$pid/task" -mindepth 1 -maxdepth 1 -type d -printf '%f\\n' | sort -n

The process directory and its task directory should exist while the shell is running. A multithreaded program will normally show several thread IDs. The top-level /proc listing exposes process directories when it is iterated, but the separate /proc/TID thread paths are not shown by ls /proc. That difference explains why a thread can be addressable without appearing as another top-level process.

For a quick system-wide view, list only numeric entries and avoid treating names such as self as PIDs:

find /proc -maxdepth 1 -mindepth 1 -type d -regex '/proc/[0-9]+' -printf '%f\\n' | sort -n | head

Processes can exit between discovery and inspection. A later No such file or directory is therefore normal for a short-lived process, not proof that procfs is broken.

4. Read system-wide files as snapshots

Names beginning with letters describe system-wide information. Read a small, portable pair of examples:

$ cat /proc/uptime
1295799.30 9058997.30
$ sed -n '1,12p' /proc/meminfo
MemTotal:       16317888 kB
MemFree:         1234567 kB

The values above are illustrative and will not match your host. /proc/uptime contains the uptime and cumulative idle time in seconds. /proc/meminfo exposes memory counters, with names and values separated by whitespace. Read these files again when making a decision: procfs is a live interface, not a frozen report, and individual reads are snapshots of changing kernel state.

Prefer a tool that already interprets a file when you need human-friendly output. For example, free is designed for memory reporting. Read the underlying proc file when diagnosing what the kernel interface actually exposes or when writing a small, controlled script.

5. Decode null-separated process data

Some proc files store strings in an internal format. The manpage specifically calls out command lines and environments: their fields end with null bytes rather than newlines. Convert those separators for inspection. Use the shell PID so the process you inspect does not change while tr runs:

$ tr '\000' '\n' < "/proc/$$/cmdline"
/bin/bash
-c
tr '\000' '\n' < "/proc/$$/cmdline"

The command line will differ. An empty-looking line or a command that changes its visible arguments is also possible. Do not assume that command-line data is secret: other local users may be able to read it unless the proc mount is restricted, and programs can deliberately alter their displayed arguments.

Do not use an unquoted variable in a proc path. This is safer when a PID comes from another command:

pid='1234'
if [ -r "/proc/$pid/status" ]; then
    sed -n '1,12p' "/proc/$pid/status"
else
    printf 'PID %s is no longer readable\\n' "$pid" >&2
fi

Replace 1234 with a PID you have deliberately selected. The read can still fail after the test if the process exits or permissions change. Treat that as a normal race.

6. Understand privacy controls before changing them

The proc filesystem supports hidepid=0, hidepid=1 and hidepid=2. The default is 0 when the option is absent: all users may access all process directories. Mode 1 leaves the directories visible but restricts files and subdirectories belonging to other users. Mode 2 also hides other users' process directories during normal directory iteration.

A proc mount can additionally use gid=GROUP. Members of that group may access process information otherwise blocked by hidepid. The manpage recommends this group-based approach instead of putting non-root users in sudoers merely to read process information.

Even hidepid=2 is not a complete process-existence barrier. The manpage notes that a known PID can be tested by other means, such as kill -0, and that a process may reveal itself through other behaviour. Treat the setting as information reduction, not a replacement for access control or application-level secrecy.

7. Check the common failure modes

• Permission denied: check the mount options and the identity running the command. Elevated privileges may be appropriate for an approved diagnostic, but sudo does not make a missing process reappear.
• Missing PID: retry the lookup. The process may have exited between listing /proc and opening its file.
• Unexpected command-line text: use tr '\000' '\n' and remember that /proc/self belongs to the reader.
• Missing thread in the top-level listing: inspect /proc/PID/task. Thread IDs are represented there, not as entries returned by normal iteration of /proc.
• A writable proc file: stop and identify exactly what it controls. Most proc files are read-only, but some writable files change kernel variables. Do not write to one from a copied example.