What is Process in Linux
Every command you’ve run in this course so far — ls, grep, find, even nano while you had it open — was a process while it ran. Some finished in a fraction of a second and vanished. Others, like a shell itself, stay alive for as long as your session does. This chapter is about what that word actually means to Linux, before the rest of this section gets into inspecting, finding, and controlling them.
A Process Is A Running Instance Of A Program
A program — say, the ls binary sitting on disk — is just a file. Nothing happens until it runs. The moment you execute it, the kernel creates a process: a running instance of that program, with its own allocated memory, its own execution state, and its own identity that the rest of the system can refer to.
This distinction matters more than it sounds like it should: the same program can be running as multiple, completely independent processes at once. Open three terminal windows, each running bash, and you have three separate bash processes — same program, three distinct running instances, each with its own state, unaware of the others.
Every Process Has A PID
The kernel identifies every process with a Process ID (PID) — a unique number assigned the moment the process starts. You’ve actually seen this concept already without dwelling on it: back in the User/Group Model chapter, /etc/passwd mapped usernames to numeric UIDs because that’s what the kernel actually tracks internally. Processes work the same way — PIDs are the real identity; process names are just a human-readable label layered on top.
PID 1 is special, and worth remembering now even though its full significance comes in the next chapter: it’s always the very first process started when Linux boots, and on nearly every modern system, that’s systemd — the same tool you’ll meet properly in the Services & Boot section later in this course.
Process States
A process isn’t simply “running” or “not running” — at any given moment, it’s in one of several distinct states, and recognizing them is essential once you start actually inspecting real processes in the next few files.
| State | Meaning |
|---|---|
Running (R) | Actively executing on the CPU right now, or ready and waiting for its turn |
Sleeping (S) | Waiting for something — input, a timer, a resource — and not currently using the CPU |
Uninterruptible Sleep (D) | Waiting specifically on I/O (disk, network) in a way that can’t be interrupted, even by a kill signal |
Stopped (T) | Paused, typically by a signal, and not executing until resumed |
Zombie (Z) | Finished executing, but still has an entry in the process table because its parent hasn’t yet collected its exit status |
Most processes you’ll ever look at spend nearly all their time in S — sleeping, waiting on something, using essentially no CPU. A process pegged in R for a long stretch is actively consuming CPU the whole time, which is exactly the kind of thing you’ll learn to spot with top later in this section. D state is worth remembering specifically because it explains a confusing situation you may eventually hit: a process stuck in D state can’t be killed with an ordinary signal, no matter how forcefully you try — a detail that will make a lot more sense once the Signals chapter covers why.
Zombie state gets a full explanation in the next chapter, since understanding it properly requires the parent-child relationship this chapter hasn’t covered yet.
A Quick First Look
You don’t need any new commands to observe this yourself — a preview using ps, which gets its own full deep-dive file shortly:
ps -o pid,ppid,stat,cmdRun this in any terminal and you’ll see a short list, including the shell you’re currently sitting in — its STAT column showing S for sleeping, since it’s doing nothing but waiting for you to type something. That PPID column — parent PID — is the thread the next chapter picks up entirely.
Processes Have Resources, Not Just A State
Beyond its state, every process holds onto resources the kernel is tracking on its behalf: a chunk of memory, open file descriptors (which includes things like actual open files but also devices and network sockets), and CPU time already consumed. This is exactly what makes runaway processes dangerous — a process stuck in a loop doesn’t just “run for a while and stop,” it keeps consuming CPU or memory indefinitely until something intervenes, which is precisely the kind of situation top and kill exist to let you diagnose and resolve later in this section.
What’s Next
You now have the core vocabulary — process, PID, state — that the rest of this section builds on constantly. The next chapter picks up the one thread left dangling here: where processes actually come from, how they relate to each other as parent and child, and what a zombie process actually is under the hood.