A program stored on disk is passive. When Linux loads that program and begins executing it, it becomes a process: a running unit with an identity, an owner, allocated resources, and a current state.
Understanding processes is essential for administering a Linux server. It lets you answer practical questions such as: What is running? Which process is consuming CPU or memory? Who started it? Is it working, waiting, stopped, or already dead? How can it be asked to exit safely?
Linux assigns every process a numeric process ID, or PID. Use ps for a snapshot of processes and top for a continuously updated view. A process state indicates what the process is doing now. The kill command sends a signal to a process; it does not necessarily terminate it immediately.
- What makes a running program a process
- How PID and PPID identify relationships between processes
- How to read process information with ps and top
- What the common Linux process states mean
- How signals and the kill command work
- How to inspect and safely stop a test process
- 🧠 What Is a Linux Process?
- Identity
- Resources
- State
- 🆔 PID, PPID, and the Process Tree
- 🔍 Inspecting Processes with ps
- Show processes with BSD-style output
- Show processes with Unix-style output
- Inspect one known PID
- Find a process by name
- 📊 Monitoring Processes with top
- 🔄 Understanding Linux Process States
- 📡 Signals and the kill Command
- Confirm the target
- Request graceful termination
- Verify the result
- Escalate only when justified
- 🧪 Mini Lab: Create, Inspect, and Stop a Process
- 1. Start the test process
- 2. Inspect it
- 3. Send SIGTERM
- 4. Verify
- ⚠️ Common Process Management Mistakes
- ✅ Knowledge Check
- Continue Learning
🧠 What Is a Linux Process?
A process is an instance of a program being executed. The same program can produce several processes. For example, a web server may create multiple worker processes from the same executable, with each worker handling work independently.
Linux tracks information about every process, including its identifier, parent, owner, memory mappings, open files, signal handling, scheduling information, and current execution state. Much of this information is exposed through the virtual /proc filesystem.
Identity
A PID uniquely identifies a process while that process exists.
Resources
A process can use CPU time, memory, files, sockets, and other kernel-managed resources.
State
A process may be running, waiting, stopped, or waiting for its parent to collect its exit status.
🆔 PID, PPID, and the Process Tree
Every process has a process ID called a PID. The kernel uses this number when applications and administrators need to refer to a specific process.
A process also normally has a parent process ID, or PPID. This identifies the process that created it. These parent-child relationships form a process tree rather than a flat list.
PID values are reusable. After a process exits and has been fully removed, its former PID may eventually be assigned to another process. A PID therefore identifies a current process, not a permanent application identity.
You can display a useful process list with explicit columns:
ps -eo pid,ppid,user,stat,etime,commThe columns mean:
| Column | Meaning | How to interpret it |
|---|---|---|
| PID | Process ID | The current numeric identity of the process |
| PPID | Parent process ID | The PID of the process that created this process |
| USER | Process owner | The account whose effective identity is shown |
| STAT | Process state and modifiers | The first character is the primary state |
| ELAPSED | Elapsed running time | How long ago the process started |
| COMMAND | Executable name | The name associated with the running command |
A process name may match several running processes, but a PID refers to one current process. Before sending a signal, confirm both the PID and the command so that you act on the intended target.
🔍 Inspecting Processes with ps
The ps command reports a snapshot. It reads process information, prints the selected rows, and exits. Its default output shows only a limited selection, so administrators normally add options.
Show processes with BSD-style output
ps auxThis commonly used form displays processes from all users with columns such as CPU usage, memory usage, PID, state, start time, and command line. Here, a, u, and x are BSD-style options and intentionally appear without a leading dash.
Show processes with Unix-style output
ps -efThis form also shows every process, but uses a different set of columns, including PID, PPID, start time, and command. Neither output is universally “better.” Choose the format that exposes the information needed for the current investigation.
Inspect one known PID
ps -p 1234 -o pid,ppid,user,stat,%cpu,%mem,etime,argsReplace 1234 with the PID you want to inspect. The custom output avoids unrelated rows and shows the complete command arguments when available.
Find a process by name
pgrep -a nginxpgrep searches running processes by name. The -a option includes the full command line in the output, which provides more context than receiving PID numbers alone.
📊 Monitoring Processes with top
Unlike ps, top provides a repeatedly updated, interactive view:
topThe upper area summarizes system activity. The process table below it shows individual processes and commonly includes PID, owner, CPU usage, memory usage, state, accumulated CPU time, and command.
Useful keys in a typical top session include:
- P — sort the process list by CPU usage
- M — sort the process list by memory usage
- k — prompt for a PID and a signal to send
- q — exit top
Interactive behavior can vary slightly between implementations and configurations. Press h inside top to view the help available on the current system.
A high value in one refresh is a clue, not a diagnosis. Watch the process across several updates, confirm its identity, and relate the activity to the workload before deciding that it is malfunctioning.
🔄 Understanding Linux Process States
A process is not continuously executing on a CPU. It frequently waits for input, timers, storage, network activity, locks, or other events. Linux represents its current condition with a state code.
| State | Name | Meaning | Should you worry? |
|---|---|---|---|
| R | Running or runnable | Executing on a CPU or ready to be scheduled | Normally expected during active work |
| S | Interruptible sleep | Waiting for an event and able to react to signals | Very common and usually normal |
| D | Uninterruptible sleep | Waiting in the kernel, commonly for I/O | Brief appearances can be normal; persistent groups need investigation |
| T | Stopped | Suspended by job control or another stop signal | Expected when deliberately paused |
| Z | Zombie | Exited, but its parent has not yet collected its termination status | An occasional short-lived zombie is possible; persistent accumulation indicates a parent-process problem |
| I | Idle kernel thread | An idle kernel-managed thread | Generally normal |
A sleeping process is not necessarily stuck. Most processes spend substantial time waiting because waiting is more efficient than consuming CPU in a loop.
A zombie is different from a running process. It has already terminated and no longer executes application code. A small process-table entry remains so its parent can read its exit status. Sending another termination signal to a zombie does not solve the underlying issue; the parent must reap it, or the process must be adopted and reaped after the parent exits.
📡 Signals and the kill Command
A signal is an asynchronous notification delivered to a process. Signals can request actions such as termination, suspension, continuation, or configuration reload. The exact response depends on the signal and on how the program handles it.
Despite its name, kill is fundamentally a signal-sending command.
Confirm the target
Inspect the PID, owner, command, and arguments before acting.
Request graceful termination
Send SIGTERM first. This gives a well-designed program an opportunity to clean up and exit.
kill 1234Verify the result
Check whether the process still exists rather than assuming the signal produced an immediate exit.
ps -p 1234Escalate only when justified
If the process cannot respond to SIGTERM and you understand the operational consequences, SIGKILL can force termination.
kill -KILL 1234Do not begin every investigation with kill -9. SIGKILL cannot be caught, blocked, or handled by the target process. It prevents normal application cleanup and may leave incomplete application-level work. Use it as an escalation, not a default.
SIGTERM is the default signal sent by kill. A program may handle it and perform an orderly shutdown. SIGKILL is enforced by the kernel and cannot be handled by the target. However, even SIGKILL may not make an uninterruptible task disappear immediately; the kernel may still be waiting for the operation responsible for its state to complete.
🧪 Mini Lab: Create, Inspect, and Stop a Process
Goal: Start a harmless background process, capture its PID, inspect its state, and stop it with SIGTERM.
1. Start the test process
The following command starts sleep in the background and stores its PID in a shell variable:
sleep 300 &
demo_pid=$!
echo "$demo_pid"2. Inspect it
ps -p "$demo_pid" -o pid,ppid,user,stat,etime,argsWhat to observe: The PID should match the value printed earlier. The process will normally show an interruptible sleeping state because it is waiting for its timer to expire.
3. Send SIGTERM
kill "$demo_pid"How to interpret it: No output usually means the signal was sent successfully. It does not, by itself, prove that the process exited.
4. Verify
ps -p "$demo_pid"If only the header appears, or ps reports no matching process, the test process is no longer present. Run these commands in the same shell so that $demo_pid retains its value.
⚠️ Common Process Management Mistakes
Interruptible sleep is a normal waiting state. A process that is not currently using CPU is often behaving efficiently.
The command sends a signal. SIGTERM may be handled or temporarily delayed, so you must verify the outcome.
Several processes may share one name. Confirm the PID, user, parent, and command arguments before sending a signal.
A zombie has already exited. The remaining entry exists because its parent has not collected the exit status, so investigation should focus on the parent.
ps provides a snapshot with its own calculation semantics, while top updates over intervals. Compare like with like and observe a pattern before diagnosing a fault.
✅ Knowledge Check
- What is the difference between a program and a process?
- What relationship does a PPID describe?
- Why is an S state usually not evidence that a process is broken?
- How do ps and top differ?
- Why should SIGTERM normally be tried before SIGKILL?
- Why does sending a signal to a zombie not fix the underlying problem?
🎓 Check Your Answers
- A program is executable code stored on disk. A process is a running instance of that program with a PID, execution state, resources, and other information managed by the kernel.
- A PPID identifies the parent that created the process. Following PID and PPID values reveals parent-child relationships within the process tree.
- The S state means the process is waiting interruptibly for an event. Waiting is normal and prevents the process from wasting CPU time while no work is available.
- ps prints a snapshot and exits. top repeatedly refreshes an interactive view, making it more useful for observing changing resource usage.
- SIGTERM allows a program to handle the request, close resources, and perform an orderly shutdown. SIGKILL gives the target no opportunity to run cleanup logic.
- A zombie has already finished executing. Its parent must collect the remaining exit status, so the unresolved parent behavior—not a still-running child—is the real issue.
A Linux process is a living execution context, not merely a program name. Identify it with its PID, understand its relationship through PPID, and interpret its state before deciding what action to take.
Use ps to inspect, top to observe, and signals to communicate. Confirm the target, prefer graceful termination, and always verify the result.
