The Anatomy of a Process

Every process has a PID, an integer unique among live processes, assigned at creation and recycled after death. It also records its parent PID — the process that forked it — so processes form a tree. On a Linux system the root of the tree is PID 1 (systemd or another init), started by the kernel at boot; everything else descends from it by fork. pstree draws the tree; the shell that launched your server is its parent, and the server’s worker processes are its children.

Lineage has consequences. A parent can wait() on its children and read their exit statuses; nobody else can. When a parent dies before its children, the children are orphaned and re-parented to PID 1 (or to a designated "subreaper" on Linux), which is what reaps them. Signals like SIGHUP on terminal close propagate along the tree via process groups and sessions, which is why closing a terminal kills the jobs started in it unless they were detached with nohup or setsid.

The kernel’s per-process record is conventionally called the process control block (PCB); in Linux it is struct task_struct, several kilobytes in size; in Windows it is the EPROCESS object. It is the process. When the scheduler switches away from a process it saves the CPU registers into this record; when it switches back it restores them from here. Everything else about the process is either in the record or reachable from a pointer in it.

Conceptually the record has these groups of fields. The list is what a process *is*, and it is the checklist for questions like "what does a fork copy?" (all of it, lazily) and "what does a thread share?" (the address space and descriptor table, not the registers or scheduling state).

The descriptor table is a per-process array; the integer you get back from open() or socket() is an index into it, and the entry points to a kernel object (an open file description with its offset and flags, which in turn points to an inode, a socket, a pipe…). Descriptors 0, 1 and 2 are just the conventional first three entries, wired by the parent before exec to a terminal, a file or a pipe. The table has a limit (ulimit -n, often 1024 by default, raisable to hundreds of thousands), and exhausting it is one of the most common production failures: every accept() and open() fails with EMFILE while the process otherwise looks healthy. See File Descriptors.

The security context is what the kernel consults on every permission check. The effective uid decides whether open("/etc/shadow") succeeds; the effective gid and supplementary groups decide group permissions. On Linux, root’s power is further split into ~40 capabilities (CAP_NET_BIND_SERVICE to bind ports below 1024, CAP_SYS_PTRACE to debug other processes, CAP_NET_RAW for raw sockets) so a process can hold one power without holding all of them — containers drop most of them by default. A process cannot raise its own privilege; it can only drop it, or exec a setuid binary that the file system has marked as running with its owner’s identity.

The kernel charges CPU time to the process that was running when the tick fired (or, with precise accounting, measures it at every switch) and splits it into user and system time. time ./server prints exactly those two numbers plus wall-clock; a program with high system time is spending its life in syscalls, a program with high user time is computing, and a program whose wall-clock greatly exceeds both is waiting. Involuntary versus voluntary context-switch counts tell you whether it is being preempted or blocking itself.

Scheduling fields are the scheduler’s input. The nice value (−20 to 19 on Unix-style systems) weights how much CPU a process gets under contention; the policy says whether it is a normal time-shared task, a real-time task that preempts everything, or a background task that only runs when nothing else wants to. The CPU affinity mask says which cores it may use — the reason a process can be "at 100%" on a 32-core box and still be the bottleneck is that 100% means one core.

On Linux every field above is readable through /proc/<pid>/: status (identity, state, uids, capabilities, memory summary, thread count, context switches), stat (the raw scheduler numbers), maps (the address space), fd/ (a symlink per open descriptor), limits, cgroup, sched. ps and top are just programs that read these files and format them; there is nothing they know that you cannot read yourself.