A web server accepting requests, an SSH session, a database worker, and even a command you run in a terminal all have something fundamental in common: Linux represents their running work as processes.
Understanding processes gives you a practical map of what a server is doing right now. It lets you answer questions such as: Which program is running? Who started it? Is it actively using the CPU or waiting? Which process created it? And what actually happens when you use kill?
A process is a running instance of a program, tracked by the Linux kernel. Processes have identifiers such as a PID, relationships such as parent and child, and a current state such as running, sleeping, stopped, or zombie.
Tools such as ps and top let you inspect processes. Signals let processes and administrators request actions such as termination, stopping, or continuation.
- How a program differs from a process.
- What PID and PPID mean.
- How parent and child processes are related.
- What common Linux process states mean.
- How to inspect processes with
ps,top, and/proc. - What signals do and why
killdoes not simply mean “kill immediately.”
- 🐧 What Is a Linux Process?
- 🔢 PID: How Linux Identifies a Process
- PID
- PPID
- User
- 🌳 Parent and Child Processes
- 🔄 Process States: Running Does Not Mean “Using CPU All the Time”
- What Is a Zombie Process?
- 🔍 Inspecting Processes with ps
- 📊 ps vs. top
- 🗂️ Processes Are Visible Through /proc
- 📡 Signals: How Processes Receive Control Events
- SIGTERM
- SIGSTOP
- SIGKILL
- 🛠️ Stopping a Process Safely
- Identify the process
- Prefer the workload’s normal management interface
- If signaling a process directly, start with the intended signal
- ⚙️ Process vs. Service: Do Not Confuse the Layers
- ⚠️ Common Process Management Mistakes
- 1. Find your shell PID
- 2. Inspect that process
- 3. Read the kernel-exposed status
- 4. Look at the wider process list
- 🧠 A Practical Mental Model
- Continue Learning
🐧 What Is a Linux Process?
A program stored on disk is not the same thing as a process. A program is executable code and associated data. When Linux starts that program, the kernel creates and tracks execution state for it. That running execution is represented as a process.
The same program can have multiple running process instances. A server application may also create additional processes or threads to perform work concurrently.
Linux tracks information associated with processes, including identifiers, credentials, scheduling state, memory mappings, open resources, and relationships with other processes. Not every detail is visible to every user, and the exact information exposed depends on permissions and system configuration.
Think of a program as a recipe and a process as one kitchen currently following that recipe. The same recipe can be used by several kitchens at once, and each active kitchen has its own state.
🔢 PID: How Linux Identifies a Process
Linux assigns processes numerical identifiers. The most familiar one is the process ID, or PID.
You can display the PID of your current shell with:
echo $$The number is useful because process-management and diagnostic tools can use a PID to refer to a particular process.
For example, a process listing can include the PID alongside the user, process state, and command:
ps -eo pid,ppid,user,stat,commThe exact processes and numbers will differ from one machine to another.
PID
Identifies a process within its PID namespace.
PPID
Identifies the process recorded as the parent.
User
Process credentials help determine what operations it may perform.
🌳 Parent and Child Processes
Processes do not exist as an unrelated flat list. Process creation produces relationships. A process can create another process, giving you a parent-child relationship.
The child’s process information records a parent process ID, commonly shown as PPID.
You can inspect these relationships with:
ps -eo pid,ppid,stat,commAnother useful view is:
ps -ef --forestOn implementations that support this option, the forest representation makes process relationships easier to see visually.
This model matters on servers because the process you notice may not be the process that originally launched the workload. A service manager can start a service, a shell can launch commands, and an application can create workers of its own.
🔄 Process States: Running Does Not Mean “Using CPU All the Time”
A process changes state as it executes and waits. One of the most useful fields in ps output is therefore STAT or S.
| State | Meaning | Beginner interpretation |
|---|---|---|
| R | Running or runnable | The task is executing or ready to execute. |
| S | Interruptible sleep | The task is waiting for an event and can be awakened. |
| D | Uninterruptible sleep | The task is waiting in a state commonly associated with I/O. |
| T | Stopped | Execution has been stopped, for example by job control. |
| Z | Zombie | The process has terminated, but its parent has not yet collected its termination status. |
Sleeping is not automatically a problem. Server processes frequently spend time waiting for network connections, timers, files, or other events instead of continuously consuming CPU.
Likewise, seeing one process in state D for a brief observation is not enough to diagnose a storage problem. Process state is evidence to interpret alongside the workload, logs, I/O behavior, and other measurements.
What Is a Zombie Process?
A zombie is already terminated. What remains is process bookkeeping that allows its parent to obtain the child’s termination information.
This distinction matters because treating a zombie as if it were an ordinary running program leads to the wrong mental model. The useful troubleshooting question is usually why the parent has not yet collected the child’s status, not how to make the already-terminated child “stop running.”
🔍 Inspecting Processes with ps
ps reports process information. Instead of memorizing a single giant command, start by choosing the fields that answer your question.
For a clear system-wide view:
ps -eo pid,ppid,user,stat,%cpu,%mem,commRead it as a table:
- PID — process ID.
- PPID — parent process ID.
- USER — process owner shown by the tool.
- STAT — process state plus possible additional status characters.
- %CPU and %MEM — utilization information reported by
ps. - COMMAND/COMM — process command name.
If you already know a PID, you can request information about that process directly. Replace 1234 with a PID that exists on your machine:
ps -p 1234 -o pid,ppid,user,stat,etime,commetime shows elapsed time since the process started.
📊 ps vs. top
ps and top overlap, but they are useful in different ways.
| Tool | Best mental model | Useful when… |
|---|---|---|
| ps | A process listing at the time the command gathers its data | You want selected fields, filtering, scripting, or a reproducible snapshot. |
| top | An updating interactive process and system view | You want to watch activity change while investigating a server. |
Run:
topThen observe rather than immediately acting. Which processes move toward the top? Does CPU activity persist or disappear? Are you seeing one busy process or many?
A single observation is not a diagnosis. Process information becomes more useful when you compare it over time and connect it to what the server is supposed to be doing.
🗂️ Processes Are Visible Through /proc
Linux exposes process and kernel information through the /proc pseudo-filesystem. For running processes, numerical directories such as /proc/1234/ expose process-related information for PID 1234, subject to access controls.
You can safely inspect your current shell using:
cat /proc/$$/statusAmong other fields, the output can include the process name, state, PID, parent PID, credentials, and thread count.
This also connects processes to an earlier Servers Academy concept: /proc appears inside the Linux directory tree, but it is not simply a directory full of ordinary persistent files. It provides an interface to live kernel information.
Commands such as ps give you a convenient process view. /proc helps reveal where much of Linux’s process information is exposed. Learning both layers makes process tools less mysterious.
📡 Signals: How Processes Receive Control Events
A signal is a mechanism used to notify a process of an event. Different signals have different meanings and default actions, and a program can define handlers for many signals.
Three names are especially useful when learning process administration:
SIGTERM
A termination signal. Its default action is to terminate, but a process can catch it and perform application-specific handling.
SIGSTOP
Stops a process. It cannot be caught, blocked, or ignored.
SIGKILL
Terminates a process and cannot be caught, blocked, or ignored.
This explains an important naming trap: the kill command is fundamentally a tool for sending signals. It does not mean that every invocation immediately forces a process out of existence.
🛠️ Stopping a Process Safely
Before sending a signal, identify the correct process and understand its role. On a server, terminating the wrong process can interrupt users, applications, remote access, or data-processing work.
Identify the process
Confirm its PID, owner, command, parent, and purpose before changing its state.
Prefer the workload’s normal management interface
If the process belongs to a systemd service, manage the service with systemctl when appropriate rather than treating one observed PID as the whole application.
If signaling a process directly, start with the intended signal
For a normal termination request, SIGTERM is commonly the appropriate starting point.
To explicitly send SIGTERM to a known process:
kill -TERM 1234Do not copy this command with an arbitrary PID. PID 1234 is only a placeholder. Verify the real process first.
SIGKILL is different:
kill -KILL 1234Because SIGKILL cannot be caught or ignored, the target process cannot use a signal handler to perform application-level cleanup in response to it. That makes SIGKILL a forceful tool, not the default first step for routine process management.
⚙️ Process vs. Service: Do Not Confuse the Layers
A process and a service are related concepts, but they are not synonyms.
A process is an execution entity tracked by the kernel. A service is a managed workload or function that may involve one or more processes. On a systemd system, a service unit describes how systemd manages that workload.
This is why manually killing one PID is not always equivalent to stopping a service. The manager may have restart policies, child processes may exist, or the application may use a more complex process model.
⚠️ Common Process Management Mistakes
Waiting is normal. Many processes spend most of their lives sleeping until work arrives.
SIGKILL gives the target no opportunity to handle the signal. First understand the process and use the normal service or application shutdown mechanism when available.
PIDs can be reused after processes exit. Re-check process identity when acting on information collected earlier.
CPU consumption can be legitimate. Interpret utilization in the context of workload, duration, expected behavior, and system performance.
A service manager operates at a higher management layer. A service can involve multiple processes and policies that are not represented by one PID alone.
Goal: connect a shell, its PID, its parent, its state, and /proc without changing the system.
1. Find your shell PID
echo $$The shell expands $$ to its process ID.
2. Inspect that process
ps -p $$ -o pid,ppid,user,stat,etime,commLook at the PID, parent PID, user, state, elapsed time, and command name.
3. Read the kernel-exposed status
cat /proc/$$/statusFind the Name, State, Pid, and PPid fields. Compare them with the information shown by ps.
4. Look at the wider process list
ps -eo pid,ppid,user,stat,commTry to find your shell again. Notice that it is only one process among many making up the running system.
How to interpret the lab: the same running entity can be viewed through user-space tools such as ps and through process information exposed under /proc. PID and PPID give you identity and relationship; state tells you what kind of scheduling or waiting condition the task is currently in.
🧠 A Practical Mental Model
When troubleshooting a Linux process, avoid jumping directly to “kill it.” Use a sequence of questions instead:
Then connect process information to the symptom you are investigating. CPU problems require CPU evidence. Memory problems require memory evidence. Service failures require service state and logs. Process inspection is the map that helps you decide where to look next.
- What is the difference between a program and a process?
- What do PID and PPID tell you?
- Does an
Sprocess state automatically indicate a problem? - Why is a zombie different from an ordinary running process?
- Why is
killbetter understood as a signal-sending command? - Why should SIGKILL usually not be your first troubleshooting action?
🎓 Check Your Answers
- A program is executable code and data, while a process represents a running execution of a program that the kernel is tracking.
- PID identifies the process in its PID namespace, while PPID records its parent process ID. Together they help identify a process and understand part of its relationship to other processes.
- No.
Smeans interruptible sleep, which is normal for processes waiting for events. Many healthy server processes spend substantial time waiting rather than consuming CPU continuously. - A zombie has already terminated. Its remaining process entry exists so the parent can collect termination information, so it should not be interpreted as an ordinary process still executing application code.
- The command sends a selected signal to a target. Termination is only one possible effect; signals can also stop, continue, or otherwise notify processes depending on the signal and process behavior.
- SIGKILL cannot be caught, blocked, or ignored, so the target cannot handle it to perform application-level cleanup. Normal service controls or an appropriate termination request should generally be considered first.
A Linux server is not simply “running programs.” The kernel tracks running work as processes with identities, relationships, states, credentials, and other runtime information.
Learn to inspect before acting: identify the PID and parent, understand the process state, determine whether a service manager owns the workload, and only then decide whether any control action is appropriate. That process-first mental model becomes the foundation for understanding CPU load, memory usage, performance, and troubleshooting.
