How to Check Running Processes in Linux

How to Check Running Processes in Linux

Understanding what's happening inside your Linux system at any given moment is crucial for maintaining optimal performance, troubleshooting issues, and ensuring system security. Every application you launch, every background service that starts automatically, and every system operation creates processes that consume resources and compete for your computer's attention. When your system slows down, when memory runs low, or when something just doesn't work as expected, knowing how to examine these processes becomes an essential skill that separates confident system administrators from frustrated users.

A running process represents an executing instance of a program in Linux, complete with its own memory space, system resources, and execution context. This comprehensive guide explores multiple methods and tools for monitoring, analyzing, and managing processes, from basic command-line utilities that have existed for decades to modern, feature-rich alternatives that provide real-time insights. Whether you're tracking down a resource-hungry application or simply want to understand what your system is doing behind the scenes, mastering process management opens a window into the inner workings of your Linux environment.

Throughout this exploration, you'll discover practical commands with real-world examples, learn to interpret process information effectively, and gain the confidence to diagnose system issues independently. From the ubiquitous ps command to interactive tools like htop, from filtering specific processes to understanding process hierarchies, you'll develop a comprehensive toolkit for process management that serves you whether you're managing a personal desktop or administering production servers.

Essential Command-Line Tools for Process Monitoring

Linux provides a rich ecosystem of command-line utilities designed specifically for process observation and management. These tools range from simple, focused commands that display basic information to sophisticated monitoring systems that track resource usage over time. Understanding when and how to use each tool transforms process management from a mysterious black box into a transparent, controllable aspect of system administration.

The Classic PS Command

The ps (process status) command remains the foundational tool for viewing running processes in Linux. Despite its age, this utility continues to be relevant because of its flexibility, scriptability, and universal availability across virtually every Linux distribution. The command displays a snapshot of current processes, capturing information at the exact moment you execute it.

When you run ps without any options, you'll see only processes associated with your current terminal session—a limited view that's rarely useful for comprehensive system analysis. The real power emerges when you combine ps with various options that expand its scope and customize its output format.

Basic ps command variations:

ps aux          # Display all processes with detailed information
ps -ef          # Alternative format showing all processes
ps -u username  # Show processes for specific user
ps -C processname  # Display processes by name
ps --forest     # Show process hierarchy as tree

The ps aux command deserves special attention as it's arguably the most commonly used variation. The 'a' option shows processes from all users, 'u' provides user-oriented format with additional details, and 'x' includes processes not attached to a terminal. This combination gives you a comprehensive system-wide view with columns showing user ownership, CPU and memory usage, process start time, and the command that initiated each process.

"The ability to see every process running on your system, understand what resources they're consuming, and identify which ones are causing problems is not just a technical skill—it's fundamental to maintaining a healthy, responsive Linux environment."

Understanding PS Output Columns

Interpreting the output from ps commands requires understanding what each column represents. The information density can seem overwhelming initially, but each field provides specific insights into process behavior and resource consumption.

The STAT column uses single-letter codes that reveal process states. Common codes include 'R' for running, 'S' for sleeping (waiting for an event), 'D' for uninterruptible sleep (usually IO), 'Z' for zombie (terminated but not reaped by parent), 'T' for stopped, and additional characters like '<' for high priority or 'N' for low priority. Understanding these states helps diagnose why processes might be unresponsive or consuming unexpected resources.

The TOP Command for Real-Time Monitoring

While ps provides snapshots, the top command offers continuous, real-time monitoring of processes and system resources. This interactive tool refreshes automatically, typically every three seconds, displaying processes sorted by CPU usage by default. The dynamic nature makes top ideal for observing system behavior over time, watching resource consumption patterns, and identifying processes that intermittently consume excessive resources.

top              # Launch interactive process monitor
top -u username  # Monitor specific user's processes
top -p PID       # Monitor specific process by ID
top -d 5         # Set refresh interval to 5 seconds

The top interface divides into two main sections. The upper section displays system-wide statistics including uptime, user count, load averages, CPU states, memory usage, and swap utilization. This summary provides context for understanding individual process behavior—a process using 50% CPU might be problematic on a single-core system but normal on a dual-core machine.

The lower section lists individual processes with columns similar to ps output. However, top's interactivity allows you to manipulate this display in real-time. Pressing 'M' sorts by memory usage instead of CPU, 'P' returns to CPU sorting, 'k' allows you to kill a process by entering its PID, 'r' lets you renice (change priority), and 'f' opens field management where you can add or remove columns from the display.

"Real-time process monitoring transforms system administration from reactive firefighting to proactive management. When you can see problems developing before they become critical, you gain the power to prevent issues rather than merely responding to them."

Advanced Process Monitoring with HTOP

The htop command represents a modern evolution of top, offering an enhanced, color-coded interface with mouse support and more intuitive controls. While not installed by default on all distributions, htop has become the preferred interactive process monitor for many system administrators due to its superior usability and visual clarity.

Installing htop varies by distribution but typically involves simple package manager commands:

# Debian/Ubuntu systems
sudo apt install htop

# Red Hat/CentOS/Fedora systems
sudo yum install htop
sudo dnf install htop

# Arch Linux
sudo pacman -S htop

The htop interface immediately distinguishes itself through color-coded CPU and memory bars at the top, making resource utilization instantly recognizable. Each CPU core gets its own bar, allowing you to see whether workloads are distributed across cores or concentrated on specific processors. Memory and swap bars use different colors to distinguish between used, buffers, and cache memory, providing more nuanced understanding than top's simple percentages.

Navigation in htop feels more natural than top. Arrow keys move through the process list, F9 opens a kill menu with signal selection, F6 allows sorting by any column, F5 switches to tree view showing parent-child relationships, and F4 provides filtering to show only processes matching specific text. The mouse support means you can click on processes to select them and click on column headers to sort, making htop accessible even to users less comfortable with keyboard-only interfaces.

Filtering and Searching for Specific Processes

System-wide process listings often contain hundreds of entries, making it impractical to manually scan for specific processes. Linux provides powerful filtering mechanisms that let you zero in on exactly the processes you need to examine, whether you're troubleshooting a specific application, monitoring a particular user's activities, or tracking down resource consumption patterns.

Using PGREP and PKILL

The pgrep command searches for processes by name or other attributes, returning only the process IDs. This focused output makes pgrep ideal for scripting and automation, where you need process IDs for further operations without the visual clutter of full process details.

pgrep firefox           # Find all Firefox processes
pgrep -u username       # Find all processes owned by user
pgrep -l apache         # List PIDs with process names
pgrep -a python         # Show PIDs with full command lines
pgrep -c sshd           # Count matching processes

The companion command pkill combines searching with termination, allowing you to kill processes by name rather than requiring you to first find their PIDs. This convenience comes with responsibility—pkill can terminate multiple processes simultaneously if multiple matches exist, so always verify what you're targeting before executing.

pkill firefox           # Terminate all Firefox processes
pkill -u username       # Kill all processes owned by user
pkill -9 processname    # Force kill with SIGKILL signal
pkill -STOP processname # Pause process execution

"The difference between a novice and an expert isn't just knowing more commands—it's knowing which tool fits which situation. Sometimes you need the comprehensive view of ps, sometimes the real-time feedback of top, and sometimes the surgical precision of pgrep."

Combining PS with GREP for Precise Filtering

Piping ps output through grep creates a powerful filtering combination that lets you apply pattern matching to process listings. This technique works universally across all Linux systems and provides flexibility that specialized tools sometimes lack.

ps aux | grep apache                    # Find Apache processes
ps aux | grep -v grep | grep python     # Exclude grep itself from results
ps aux | grep [a]pache                  # Alternative to exclude grep
ps -ef | grep -E 'mysql|postgres'       # Find multiple process types

The grep -v grep pattern addresses a common annoyance—when you grep for a process name, grep itself appears in the results because your search term is part of the grep command line. The alternative grep [a]pache syntax achieves the same filtering through a clever trick: the brackets create a character class that matches 'apache' but doesn't literally contain 'apache' as a string, so the grep process itself doesn't match.

Using PIDOF for Simple Process ID Lookup

The pidof command provides the simplest way to find process IDs by program name. Unlike pgrep, which uses pattern matching, pidof requires exact program names, making it faster and more predictable for straightforward lookups.

pidof sshd              # Get PID of SSH daemon
pidof -s firefox        # Return only one PID if multiple exist
pidof apache2 nginx     # Find PIDs for multiple programs

The limitation of pidof is that it only searches by the program name itself, not by command-line arguments or other process attributes. This makes it perfect for finding system services and daemon processes but less useful for applications that run multiple instances with different arguments.

Understanding Process Hierarchies and Relationships

Processes in Linux don't exist in isolation—they form hierarchical relationships where parent processes spawn child processes, creating a tree structure rooted at the init system (traditionally PID 1). Understanding these relationships becomes crucial when troubleshooting application behavior, managing process groups, or ensuring that killing a parent process properly terminates its children.

Viewing Process Trees with PSTREE

The pstree command visualizes process hierarchies as an ASCII tree diagram, making parent-child relationships immediately apparent. This visualization helps you understand how processes are organized and identify which processes will be affected when you terminate a parent.

pstree                  # Show complete process tree
pstree -p               # Include process IDs
pstree -u               # Show user transitions
pstree username         # Show tree for specific user
pstree -p PID           # Show subtree from specific process

The tree structure reveals important relationships. For example, a web server might show a parent process with multiple child worker processes. If you kill the parent, the children typically terminate automatically. Conversely, orphaned processes (children whose parents terminated without cleaning them up) get adopted by the init system, which explains why you sometimes see processes with parent PID 1 that weren't directly started by the init system.

Parent and Child Process Identification

The PPID (Parent Process ID) field in ps output reveals which process spawned each process. This information becomes invaluable when tracing the origin of unexpected processes or understanding application architectures.

ps -ef                  # Shows PID and PPID columns
ps -o pid,ppid,cmd      # Custom output with specific columns
ps --ppid 1             # Show all direct children of init

Examining PPIDs helps you understand process lifecycles. A process with PPID 1 either started at boot through the init system or became orphaned when its original parent terminated. Processes with PPIDs matching your shell's PID are processes you directly launched from that terminal session. This knowledge helps distinguish between system processes, user applications, and background services.

"Process hierarchies aren't just technical details—they represent the actual architecture of how applications work. A browser with dozens of child processes isn't broken; it's using process isolation for security. Understanding this distinction prevents unnecessary troubleshooting of normal behavior."

Advanced Process Information and Analysis

Beyond basic process listings, Linux provides detailed information about each process through the /proc filesystem. This virtual filesystem exposes kernel data structures as readable files, allowing you to examine process internals with standard text tools. Each running process has a directory under /proc named with its PID, containing files that reveal everything from open file descriptors to memory maps.

Exploring the /proc Filesystem

The /proc filesystem transforms kernel data into human-readable (or at least human-parseable) format. For any process, you can navigate to /proc/PID and examine numerous files that expose different aspects of process state.

cat /proc/PID/status        # Comprehensive process status
cat /proc/PID/cmdline       # Command line that launched process
cat /proc/PID/environ       # Environment variables
ls -l /proc/PID/fd          # Open file descriptors
cat /proc/PID/maps          # Memory mapping
cat /proc/PID/limits        # Resource limits

The status file deserves particular attention as it contains structured information about process state, memory usage, thread count, signal masks, and more. Unlike ps output that provides a snapshot of selected fields, the status file gives you comprehensive detail about a single process, making it ideal for deep-dive troubleshooting.

Using LSOF to Track Open Files

The lsof (list open files) command reveals which files, network connections, and other resources a process has opened. Since "everything is a file" in Unix philosophy, this includes regular files, directories, network sockets, pipes, and devices. Understanding what a process has open helps diagnose issues like "file in use" errors, network connection problems, or resource leaks.

lsof -p PID                 # Show all files opened by process
lsof -c processname         # Show files opened by named process
lsof -u username            # Show files opened by user
lsof -i                     # Show network connections
lsof -i :80                 # Show processes using port 80
lsof /path/to/file          # Show which processes have file open

Network troubleshooting particularly benefits from lsof. When a service fails to start because "address already in use," running lsof -i :PORT immediately identifies which process is occupying that port. Similarly, when investigating security incidents, lsof reveals all network connections a suspicious process has established.

Monitoring System Calls with STRACE

The strace command traces system calls and signals, providing unprecedented visibility into what a process is actually doing at the kernel interface level. While the output can be overwhelming, strace becomes invaluable when debugging application behavior, understanding performance bottlenecks, or diagnosing mysterious failures.

strace command              # Trace system calls of command
strace -p PID               # Attach to running process
strace -c command           # Count and summarize system calls
strace -e open command      # Trace only specific system calls
strace -o output.txt command # Save trace to file

Reading strace output requires understanding system calls, but even without deep knowledge, you can identify patterns. Repeated failed open() calls might indicate missing files, EACCES errors point to permission problems, and excessive read/write calls suggest I/O bottlenecks. The -c option provides a summary that's more digestible than the full trace, showing which system calls dominate execution time.

"When application logs say nothing, when debugging output provides no clues, and when behavior defies explanation, strace reveals the truth. System calls don't lie—they show exactly what the program asked the kernel to do and what the kernel's response was."

Process Resource Management and Prioritization

Understanding which processes are running is only the first step—managing their resource consumption and execution priority ensures system responsiveness and fairness. Linux provides mechanisms for controlling how much CPU time processes receive, limiting their memory usage, and adjusting their scheduling priority to match their importance.

Understanding and Managing Process Priority

Linux uses a priority system called "niceness" that determines how much CPU time the scheduler allocates to each process. The nice value ranges from -20 (highest priority) to 19 (lowest priority), with 0 being the default. The name derives from the idea that increasing a process's nice value makes it "nicer" to other processes by yielding more CPU time to them.

Starting a process with modified priority uses the nice command, while adjusting priority of running processes requires renice:

nice -n 10 command          # Start command with nice value 10
nice -n -5 command          # Start with higher priority (requires root)
renice -n 5 -p PID          # Change priority of running process
renice -n 5 -u username     # Change priority for all user's processes

Important security note: regular users can only increase nice values (lower priority) for their own processes. Decreasing nice values (increasing priority) requires root privileges, preventing users from unfairly monopolizing CPU resources at the expense of other users or system services.

Limiting Resource Consumption with ULIMIT

The ulimit command sets resource limits for processes, preventing runaway applications from consuming all available system resources. These limits include maximum CPU time, memory usage, file sizes, and number of open files, among others.

ulimit -a                   # Display all current limits
ulimit -n 4096              # Set maximum open files
ulimit -u 100               # Limit number of processes
ulimit -v 1000000           # Limit virtual memory (KB)
ulimit -t 600               # Limit CPU time (seconds)

Limits set by ulimit apply to the current shell and its child processes, making them useful for controlling specific applications without affecting the entire system. For persistent, system-wide limits, you would modify /etc/security/limits.conf instead.

Practical Process Management Scenarios

Theory becomes meaningful when applied to real-world situations. The following scenarios demonstrate how to combine various process management tools to solve common problems that system administrators and users encounter regularly.

🔍 Identifying Resource-Heavy Processes

When your system slows down, the first question is usually "what's consuming resources?" A systematic approach combines multiple tools to identify the culprit:

# Quick overview of top CPU consumers
ps aux --sort=-%cpu | head -n 10

# Quick overview of top memory consumers
ps aux --sort=-%mem | head -n 10

# Real-time monitoring to catch intermittent issues
top -d 1

# Detailed analysis of specific process
lsof -p PID
cat /proc/PID/status

This layered approach starts with a quick snapshot, then moves to real-time monitoring if the problem isn't immediately obvious, and finally dives into detailed analysis once you've identified the problematic process. The sorting capabilities of ps make it easy to identify outliers without the constant refresh of interactive tools.

🛑 Safely Terminating Unresponsive Processes

Killing processes requires understanding signal types. The default SIGTERM (15) asks a process to terminate gracefully, giving it time to clean up resources and save state. SIGKILL (9) forces immediate termination without cleanup, used only when SIGTERM fails.

# Graceful termination (preferred)
kill PID
kill -15 PID                # Explicit SIGTERM

# Wait 10 seconds, then check if still running
sleep 10
ps -p PID

# Force kill if still running
kill -9 PID

# Kill by name (affects all matching processes)
pkill processname
pkill -9 processname        # Force kill by name

Always attempt graceful termination first. Applications that handle SIGTERM properly close files, flush buffers, save state, and release resources cleanly. Jumping straight to SIGKILL risks data corruption, orphaned resources, and inconsistent state. Only use SIGKILL when a process is truly unresponsive to SIGTERM or when immediate termination is required for security reasons.

🔎 Investigating Suspicious Processes

Security incidents or unusual system behavior often require investigating unfamiliar processes. A thorough investigation examines multiple aspects of the process to determine its legitimacy:

# Identify the process
ps aux | grep suspicious_name

# Examine full command line and parent process
ps -ef | grep PID

# Check what files it has open
lsof -p PID

# See network connections
lsof -i -p PID

# Examine the executable
ls -l /proc/PID/exe

# View process environment
cat /proc/PID/environ | tr '\0' '\n'

# Check process start time
ps -o lstart= -p PID

Legitimate processes typically have recognizable names, run from standard system directories like /usr/bin or /usr/sbin, and have parent processes that make sense (like systemd for services or your shell for user applications). Suspicious indicators include processes running from temporary directories, unusual parent processes, unexpected network connections, or names that mimic legitimate processes with subtle misspellings.

⚙️ Monitoring Long-Running Background Tasks

Background tasks like backups, data processing, or compilation need monitoring to ensure they're progressing normally and not consuming excessive resources. A combination of process monitoring and resource tracking provides this visibility:

# Start task with lower priority
nice -n 10 ./long_running_task &

# Get its PID
PID=$!

# Monitor its progress periodically
watch -n 5 "ps -o %cpu,%mem,etime,cmd -p $PID"

# Check I/O activity
iotop -p $PID

# Monitor in detail with htop
htop -p $PID

The watch command repeatedly executes a command at specified intervals, creating a simple dashboard for monitoring process evolution. The etime field shows elapsed time, helping you estimate completion based on progress so far.

📊 Analyzing Process Patterns Over Time

Sometimes you need to understand process behavior patterns rather than just current state. Logging process information over time creates a historical record for analysis:

# Log top processes every 60 seconds
while true; do
    date >> process_log.txt
    ps aux --sort=-%cpu | head -n 10 >> process_log.txt
    echo "---" >> process_log.txt
    sleep 60
done &

# Or use a one-liner for specific process
while true; do
    echo "$(date): $(ps -o %cpu,%mem -p PID --no-headers)" >> specific_process.log
    sleep 30
done &

This historical data reveals patterns like memory leaks (gradually increasing memory usage), periodic spikes (scheduled tasks), or correlation between different processes. Analysis of these logs often uncovers issues that aren't apparent from momentary snapshots.

Specialized Tools for Specific Situations

Beyond the general-purpose tools covered earlier, Linux offers specialized utilities designed for specific monitoring scenarios. Understanding when to reach for these tools expands your troubleshooting capabilities significantly.

Using IOTOP for I/O Monitoring

The iotop command provides a top-like interface specifically for disk I/O, showing which processes are reading from or writing to disk. This becomes crucial when investigating system slowdowns caused by disk bottlenecks rather than CPU or memory constraints.

sudo iotop                  # Launch I/O monitor (requires root)
sudo iotop -o               # Show only processes doing I/O
sudo iotop -p PID           # Monitor specific process
sudo iotop -a               # Show accumulated I/O instead of bandwidth

Disk I/O bottlenecks manifest differently than CPU bottlenecks. The system might appear to have plenty of free CPU and memory, yet feel sluggish because processes are waiting for disk operations. Iotop identifies these situations by showing which processes are generating I/O load and whether reads or writes dominate.

Network Activity Monitoring with NETHOGS

While lsof shows network connections, nethogs displays bandwidth usage per process, answering the question "which application is using all my network bandwidth?" This becomes particularly valuable on systems with limited connectivity or when investigating unexpected network traffic.

sudo nethogs                # Monitor network usage by process
sudo nethogs eth0           # Monitor specific interface
sudo nethogs -d 5           # Update every 5 seconds

Nethogs groups traffic by process and displays sent and received bandwidth, making it immediately clear which applications are network-intensive. This visibility helps identify bandwidth hogs, detect unexpected network activity that might indicate malware, or verify that bandwidth-limited applications are respecting their constraints.

System-Wide Performance with VMSTAT and SAR

The vmstat command reports system-wide statistics about processes, memory, paging, block I/O, interrupts, and CPU activity. Unlike process-specific tools, vmstat provides the big picture of system health:

vmstat 5                    # Report every 5 seconds
vmstat 5 10                 # Report 10 times, 5 seconds apart
vmstat -s                   # Display memory statistics
vmstat -d                   # Display disk statistics

The sar (System Activity Reporter) command collects, reports, and saves system activity information, creating historical records that enable trend analysis. While more complex than vmstat, sar provides comprehensive system monitoring:

sar -u 5 10                 # CPU usage, 5 second intervals, 10 times
sar -r 5 10                 # Memory usage statistics
sar -b 5 10                 # I/O and transfer rate statistics
sar -n DEV 5 10             # Network statistics

These system-wide tools contextualize process behavior. A process using 50% CPU might seem problematic until vmstat reveals the system is mostly idle, indicating the process is simply the only active workload rather than competing with others.

How do I find which process is using the most CPU?

Use the command ps aux --sort=-%cpu | head -n 10 to display the top 10 CPU-consuming processes. Alternatively, run top or htop for real-time monitoring, where processes are sorted by CPU usage by default. In top, press 'P' to ensure CPU sorting is active. The %CPU column shows the percentage of CPU time each process is consuming.

What's the difference between kill and kill -9?

The standard kill command sends SIGTERM (signal 15), which requests that a process terminate gracefully, allowing it to clean up resources, save data, and exit properly. The kill -9 command sends SIGKILL (signal 9), which forces immediate termination without any cleanup opportunity. Always try SIGTERM first, using SIGKILL only when a process is unresponsive or when immediate termination is required.

How can I see all processes running on my Linux system?

Execute ps aux or ps -ef to display all running processes system-wide. For an interactive, continuously updating view, use top or htop. The ps aux format provides user-oriented output with CPU and memory usage, while ps -ef shows full-format listing including parent process IDs. Both display processes from all users, not just your own.

What does it mean when a process is in 'Z' state (zombie)?

A zombie process has completed execution but still has an entry in the process table because its parent hasn't read its exit status. Zombies consume no system resources except the process table entry. They typically disappear when the parent process reads their status or when the parent terminates. Persistent zombies indicate a bug in the parent process that's failing to properly wait for its children.

How do I monitor a specific process continuously?

Use top -p PID or htop -p PID to monitor a specific process interactively. For logging over time, use watch -n 5 "ps -o %cpu,%mem,etime -p PID" to display updated statistics every 5 seconds. To log to a file, create a loop: while true; do echo "$(date): $(ps -o %cpu,%mem -p PID --no-headers)" >> monitor.log; sleep 30; done.

Why can't I see all processes when I run ps?

Running ps without options shows only processes associated with your current terminal session. To see all processes, use options like ps aux (all processes with detailed info), ps -ef (all processes in full format), or ps -e (all processes, minimal info). The 'a' option shows processes from all users, 'x' includes processes without controlling terminals, and 'u' provides user-oriented format.

How do I find which process is using a specific port?

Use sudo lsof -i :PORT replacing PORT with the actual port number, such as sudo lsof -i :80 for HTTP. Alternatively, sudo netstat -tulpn | grep :PORT or sudo ss -tulpn | grep :PORT will show the process using that port. Root privileges are typically required to see processes owned by other users.

What's the best way to monitor system performance in real-time?

For general monitoring, htop provides the most user-friendly real-time view with color-coded CPU, memory, and swap usage. For CPU-specific monitoring, use top or mpstat. For I/O bottlenecks, iotop is essential. For network bandwidth, try nethogs. For comprehensive system statistics, vmstat 5 updates every 5 seconds. Combining tools gives the most complete picture.