Processes & /proc
ps, top, and what a process really is.
A process is a running program — when you launch something, the kernel creates a process, gives it a PID (process ID), and tracks it. Every process has an owner (the user it runs as, which decides its privileges), a parent that started it, and its own view of memory. PID 1 is special: it is the init system (systemd), the ancestor of every other process. Reasoning about processes — who owns them, what they are doing, why one is stuck — is daily operational work.
$ ps aux | head -3 # every process: user, PID, CPU/MEM, commandUSER PID %CPU %MEM COMMANDroot 1 0.0 0.1 /sbin/init # PID 1 = systemd, the ancestor of allwww-data 812 0.3 1.2 nginx: worker process$ ps -ef --forest # the parent/child tree$ pgrep -a sshd # find PIDs by name, with their command lines
Live views: top and /proc
ps is a snapshot; top (or the nicer htop) is a live, updating view of what is consuming CPU and memory right now — your first stop when a server is slow. And because everything is a file, /proc/<pid>/ exposes deep detail about any process: its command line, environment, open files, and limits. When you need to know exactly what a suspicious process is doing, /proc is the ground truth, readable with the same tools you already know.
$ top # live CPU/MEM by process (q to quit, M sorts by memory)$ ls -l /proc/812/exe # the actual binary a PID is running (great for spotting fakes)$ cat /proc/812/cmdline | tr '\0' ' ' # the exact command line$ ls -l /proc/812/fd # every file/socket the process has open
Why the owner of a process matters
A process can only do what its owning user can do, so "what user is this running as?" is a security question with real weight. A web server running as root is dangerous — a bug in it becomes root code execution — which is exactly why services run as dedicated low-privilege users. When you investigate, the owner column tells you the blast radius: a compromised www-data process is bad; a compromised root process is an emergency.