Prefer to click through the interactive model?
Processes — study guide
The same fragments the interactive model serves, read in order. One source, two views.
A program that is running
A process is a program that is actually running. The program itself is just a file sitting on disk doing nothing; the moment the operating system loads it and sets it going, that live, executing copy is a process. Everything happening on a machine right now — the shell you typed in, the browser, the background service you forgot about — is a process.
The operating system does not treat these as anonymous activity. It gives each process an identity, tracks what state it is in, and decides when it gets to run. A process is born, it runs and waits and runs again, and eventually it ends, either because it finished or because something stopped it.
That shepherding is the whole subject here: how the system names a running process, moves it through its life, and how you reach in from the outside to inspect one or make it stop. Knowing it turns "the thing is stuck" from a mystery into something you can find and act on.
Program on disk, process in motion
A program and a process are not the same thing, and the difference is worth getting straight early. A program is a file of instructions at rest — bytes on disk, going nowhere until something runs them. A process is one running copy of that program, loaded into memory and actively executing. It works like a recipe versus cooking it — the recipe is the instructions at rest, and a cook actually working through them is the doing; one recipe can have several cooks each working their own copy at once: the program is the instructions written down, and the process is those instructions actually being carried out.
The one-to-many part is what surprises people. A single program can be running as many separate processes at the same time, each its own independent instance with its own identity and its own place in its work. Open three terminal windows and you have one shell program running as three distinct processes; the file on disk was never copied, but there are three live executions of it.
So "the program" and "a process of it" are different questions. The file is what you install and delete; a process is what you find running and, when it misbehaves, what you stop.
Every process has a PID
When the operating system starts a process, it assigns it a process id — a PID, a plain number that names that one running process and no other. The PID is how you point at a specific process from the outside: to inspect it, to ask what state it is in, or to send it a signal. Without it, "that process" is just a gesture; with it, you have an exact address.
The number belongs to the running instance, not to the program. Two processes of the same program have two different PIDs, and once a process ends its PID can later be reused for something else, so a PID identifies a process only while that process is alive. Your own shell is a process too, with a PID you can read — the shell variable $$ expands to it on Unix, and PowerShell reports its session's id in $PID.
Everything you do to a running process starts by naming it this way. Find the PID, and inspecting or stopping the right thing stops being guesswork.
The life of a process
A process does not simply run from start to finish. It moves through a small set of states, and at any instant it is in exactly one of them. It is ready when it could run but is waiting for its turn on the CPU; it is running when it is actually executing on the CPU; it is blocked when it is waiting for something outside itself, usually input or output, and cannot proceed until that arrives; and it is terminated once it has ended.
The moves between those states are the mechanism. A process can only run on a CPU one at a time per core, so the operating system's scheduler picks which ready process runs next and dispatches it. A running process that asks for I/O goes blocked until the data is there, then returns to ready to wait its turn again. If it uses up its slice of time, the scheduler preempts it straight back to ready so another process gets a turn. When it finishes or is stopped, it moves to terminated.
You can read these states directly. In ps output the STAT column shows a code per process: R for running or runnable, S for interruptible sleep (waiting on an event), D for uninterruptible sleep (usually disk I/O), T for stopped, and Z for a zombie — a process that has terminated but whose exit has not yet been collected by its parent. A process that seems frozen is often just sitting in D, waiting on I/O that never came, which is a very different problem from one spinning at full tilt in R.
Signals, and what killing means
A signal is a small message the operating system delivers to a process — a notification that something has happened or a request that it do something, most often that it stop. "Killing" a process sounds dramatic, but it is nothing more than sending it one of these signals. The interesting part is that not all signals are equal, and the difference decides whether a process gets to end on its own terms.
SIGTERM, signal number 15, is the polite request. It tells a process to shut down, and the process can catch it — run its own handler to save its work, close files, and exit cleanly — or even ignore it. SIGKILL, signal number 9, is the opposite: the kernel stops the process immediately, and it cannot be caught, blocked, or ignored. There is no handler, no cleanup, no last word. It works like asking someone to finish up and leave, so they can save their work and tidy, versus physically carrying them out mid-task with no chance to clean up: SIGTERM asks the process to wrap up and leave under its own power, while SIGKILL removes it on the spot with no chance to tidy up.
That ordering is the practical rule. Send SIGTERM first and give the process a moment to exit gracefully, because a clean shutdown is almost always what you want; reach for SIGKILL only when a process ignores the polite request and will not stop any other way. The force always works, but it costs the process any chance to leave things in order.
Processes come from processes
Every process is started by another process. There is no such thing as a process that appears from nowhere: one already-running process launches another, and the one that did the launching is the parent, the new one its child. Run a command from your shell and the shell is the parent of the process that command becomes. This makes every process on a machine part of one big family tree, tracing back through parents to the first process the system started at boot.
Just as a process records its own PID, it records its parent's — the parent process id, or PPID. The pair is what lets you walk the tree: given a process you can find who started it, and given a process you can find what it started. When you look at your own shell's PPID, you are looking at whatever program opened the terminal for you.
Parents and children are also tied together at the end. When a process finishes, its parent is expected to collect its exit status; a process that has ended but not yet been collected lingers as a zombie in the table until it is. And when a parent ends before its children, those children are not lost — the system hands them off to be adopted rather than leaving them orphaned, so they keep running with a new parent.
Finding and stopping the right thing
The reason all of this earns its keep is the moment something goes wrong. A game server that stops responding, a robot control script that hangs, a build that never finishes — each is a process, and each becomes tractable the instant you think of it as one. You find it in the process list, read its PID, and decide what to do from there.
The two everyday questions both have process-shaped answers. "Is it still running?" is answered by looking for it in the process list: if it has a live PID and a state, it is running; if it is gone, it is not. "How do I make it stop?" is answered by sending it a signal — SIGTERM to ask it to shut down cleanly, and only SIGKILL when it refuses. Reading its state first tells you which you are dealing with, a process burning CPU or one wedged waiting on I/O.
So the habit is small and general. Before you restart, reinstall, or panic, find the process, name it by its PID, and stop the right one the right way. It is the same move whether the thing is on your laptop, a server, or a small board taped to a robot.