Practical Guide to Viewing and Controlling Processes in Linux! Master Process Management with 5 Commands to Eliminate Lag and Crashes

Practical Guide to Viewing and Controlling Processes in Linux! Master Process Management with 5 Commands to Eliminate Lag and Crashes

In daily Linux operations, process management is one of the core skills — when the system lags, services become unresponsive, or resource usage anomalies need to be investigated, it is essential to “view processes” to locate the problem, and then “control processes” (such as terminating, pausing, or restarting) to resolve the issue.

However, for beginners, facing numerous process commands (like ps/top/kill, etc.), it can be overwhelming to know where to start. In this article, we will use a “scenario-based practical” approach to help you master the core commands for viewing and controlling processes, accompanied by intuitive illustrations and pitfalls to avoid, enabling you to quickly resolve process issues!

1. First, clarify: the “core logic” of process viewing and control

The essence of Linux process management is “locate first, then operate” — by using viewing commands to obtain the process’s PID, resource usage, status, and other information, and then executing corresponding control commands based on the type of problem (such as terminating unresponsive processes or adjusting process priority).

First, look at a “process viewing and control flow diagram” to help you establish an overall understanding:

**

Core principles:

When viewing processes, prioritize using top for real-time monitoring of dynamic changes (such as CPU/memory usage fluctuations), and use ps to obtain static detailed information (such as PID, PPID, command path);

Before controlling a process, you must confirm the target process’s PID (to avoid mistakenly operating on other processes), especially when terminating a process, you need to first determine whether the process is a critical system process (like systemd, PID=1, which should not be terminated);

When terminating a process, prioritize using gentle signals (like SIGTERM, signal 15), and if ineffective, then use a forceful signal (like SIGKILL, signal 9) to avoid data loss.

2. Process Viewing: 3 Core Commands Covering All Scenarios

The core requirement for process viewing is “to obtain key information”; different scenarios require different dimensions of information (such as real-time monitoring, static details, process tree relationships). We will explain 3 core commands sorted by “usage frequency + scenario adaptation”.

1. top: Real-time monitoring of process dynamics (a must-use for system lag)

Core function: Displays the resource usage of processes (CPU, memory, IO) in real-time, sorted by resource usage, supports interactive operations (such as filtering, killing processes), and is the “preferred tool” for troubleshooting system lag and resource exhaustion.

Command format: Simply enter top (defaults to refreshing every 3 seconds, press q to exit).

(1) Interpreting the top interface information

After entering top, the interface is divided into the “system overview area” and the “process list area”; understanding the information in these two areas is essential for quickly locating problems:

**

① System overview area (first 5 lines):

Line 1: System time, uptime, number of logged-in users, system load (load average: 0.50, 0.30, 0.20, representing the average load over 1 minute, 5 minutes, and 15 minutes respectively; lower values indicate more idle time, and exceeding the number of CPU cores indicates excessive load);

Line 2: Total number of processes (Tasks: 150 total), number of running processes (1 running), number of sleeping processes (148 sleeping), number of stopped processes (0 stopped), number of zombie processes (1 zombie);

Line 3: CPU usage (%Cpu(s): 10.0 us, us = user process usage, sy = system process usage, id = idle CPU, wa = IO wait usage; high wa indicates an IO bottleneck);

Lines 4-5: Memory usage (Mem = physical memory, Swap = swap space, used = used, free = free, buff/cache = cache and buffers, available = available memory).

② Process list area (key fields):

Field

Meaning

Core function

PID

Process ID

Uniquely identifies the process, key to controlling the process

USER

User to whom the process belongs

Determines whether the process was created by a normal user or root

%CPU

Process CPU usage rate

Locates processes with high CPU usage

%MEM

Process memory usage rate

Locates processes with high memory usage

VSZ

Process virtual memory size (KB)

Total amount of virtual memory occupied by the process

RSS

Process physical memory size (KB)

Actual physical memory occupied by the process

TTY

Terminal associated with the process

? indicates no terminal (background process), pts/0 indicates terminal process

STAT

Process status

Refer to previously discussed R/S/D/T/Z states to determine if the process is normal

START

Process start time

Check if the process has been running for a long time

TIME

Total CPU time accumulated by the process

Check total CPU consumption of the process

COMMAND

Process start command

View the corresponding program for the process (like nginx, java)

(2) Interactive operations in top (efficient usage tips)

top supports various shortcuts for quickly filtering, sorting, and operating processes; beginners must master the following high-frequency operations:

Press P: Sort by CPU usage in descending order (default sorting, quickly find processes with high CPU usage);

Press M: Sort by memory usage in descending order (find processes with high memory usage);

Press T: Sort by total CPU time in descending order (find processes that have long occupied CPU);

Press k: Kill the process with the specified PID (enter PID and press Enter, then enter the signal number, such as 15 or 9);

Press u: Filter processes by specified user (enter username, such as root or zhangsan);

Press q: Exit the top interface.

Practical case: Use top to locate processes with high CPU usage

When the system lags and you suspect a process is consuming too much CPU:

1. Enter top to start real-time monitoring

top

2. Press P to sort by CPU usage in descending order, find the process with the highest %CPU (assuming PID=1234, COMMAND=java)3. Check the detailed information of that process: USER=root, %CPU=90.0, determine if it is an abnormal process4. If confirmed as an abnormal process (like a hung Java program), press k to kill the process:Enter PID=1234→press Enter→enter signal 15 (gentle termination)→press Enter5. If the process has not terminated after 10 seconds, press k to re-enter PID=1234, enter signal 9 (force termination)

1. ps: Obtain static detailed information about processes (essential for precise localization)

Core function: Obtain a static snapshot of processes (information at a certain moment), supports various parameter combinations, can output detailed information such as PID, PPID, command path, process status, etc., suitable for scenarios requiring precise localization of process paths or parent process relationships.

Command format: ps [parameter combination], beginners commonly use the following 3 parameter combinations:

(1) ps aux: View all users’ processes (most commonly used)

a= display all user processes, u= display user information, x= display processes without a terminal (background processes), combined to view detailed information of all processes in the system.

Practical case: Use ps aux to find the PID and path of the nginx process

View all processes, filter for nginx-related processes

ps aux | grep nginx

Output example (key field interpretation):root 900 0.0 0.2 12345 6789 ? Ss 10:00 0:00 nginx: master process /usr/sbin/nginxnginx 901 0.1 0.3 12567 8901 ? S 10:00 0:05 nginx: worker processnginx 902 0.1 0.3 12567 8902 ? S 10:00 0:04 nginx: worker processInterpretation:nginx master process: PID=900, USER=root, COMMAND=/usr/sbin/nginx (start path), STAT=Ss (interruptible sleep, session leader);nginx worker processes: PID=901/902, USER=nginx, responsible for handling client requests.

(2) ps -ef: View the parent process relationship of processes (trace back the source of processes)

-e= display all processes, -f= display complete information (including PPID, UID, C, STIME, CMD), focus on PPID (parent process ID), which can trace back the creation source of the process.

Practical case: Use ps -ef to find the parent process of a process

View the parent process of the nginx worker process with PID=901

ps -ef | grep 901

Output example:nginx 901 900 0 10:00 ? 00:00:05 nginx: worker processInterpretation: PPID=900, indicating that the parent process of PID=901 is the nginx master process with PID=900, consistent with nginx’s multi-process model.

(3) ps -l: View processes of the current terminal (simplified output)

-l= display long format information, only includes processes of the current terminal, output is concise, suitable for viewing command processes running in the current terminal.

Practical case: View processes of the current terminal

Enter ps -l to view processes of the current terminal

ps -l

Output example:F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD0 S 1000 1234 1000 0 80 0 – 25000 wait pts/0 00:00:00 bash0 R 1000 5678 1234 0 80 0 – 30000 – pts/0 00:00:00 psInterpretation:bash process (PID=1234) is the shell process of the current terminal, the ps process (PID=5678) has bash as its parent process (PPID=1234).

1. pstree: View process tree (intuitive display of parent-child relationships)

Core function: Displays the parent-child relationships of processes in a tree format, clearly showing the creation hierarchy of processes (e.g., systemd→sshd→bash→ps), suitable for troubleshooting “process proliferation” (e.g., a process creating a large number of child processes leading to resource exhaustion).

Command format: pstree [parameters], commonly used parameters:

-p: Display the PID of each process;

-u: Display the user to whom the process belongs;

-h: Highlight the processes of the current terminal.

Practical case: Use pstree to view the system process tree

View the process tree, displaying PIDs and users, highlighting the current terminal process

pstree -pu | head -25

Output example (simplified version):systemd(1,root)─┬─NetworkManager(567,root)├─sshd(890,root)─┬─sshd(1230,root)───bash(1234,zhangsan)───pstree(5678,zhangsan)│ └─sshd(1560,root)───bash(1564,lisi)├─nginx(900,root)─┬─nginx(901,nginx)│ └─nginx(902,nginx)└─mysql(1000,mysql)─┬─mysql(1001,mysql)└─mysql(1002,mysql)Interpretation:systemd (PID=1, root) is the parent process of all processes;sshd (PID=890, root) created two child processes sshd (1230/1560), corresponding to the login terminals of zhangsan and lisi;The currently executing pstree process (PID=5678, zhangsan) has bash (1234, zhangsan) as its parent process, which has been highlighted.

3. Process Control: 4 Core Commands to Solve All Process Problems

The core requirement for process control is “to adjust the process state”, including terminating unresponsive processes, adjusting process priority, pausing/resuming processes, sending custom signals, etc. We will explain these sorted by “usage frequency + operational risk”.

1. kill: Terminate processes (most commonly used, must be cautious)

Core function: Sends a “signal” to the process, achieving operations like “terminate”, “pause”, “restart” through different signals, among which the most commonly used is the “terminate signal”, used to resolve unresponsive processes or high resource usage issues.

Command format:

Send signal by PID: kill [signal number] processPID;

Send signal by process name (requires installing pkill): pkill [signal number] process name (batch terminate processes with the same name).

(1) Must-master 3 commonly used signals

Linux has 64 types of signals; beginners only need to master 3 core signals to handle 90% of scenarios:

Signal Number

Signal Name

Function

Applicable Scenarios

1

SIGHUP

Restart process (reload configuration file without terminating the process)

After modifying the configuration file, it can take effect without terminating the process (like nginx, apache)

15

SIGTERM

Gentlely terminate process (default signal, process will release resources before exiting)

Normally terminate unresponsive processes, prioritize using to avoid data loss

9

SIGKILL

Forcefully terminate process (directly kill the process, does not release resources, may lead to data loss)

Use when SIGTERM is ineffective (like a completely hung process, unresponsive)

Practical case 1: Use SIGHUP to restart nginx (load new configuration)

After modifying the nginx configuration file, use signal 1 to let nginx reload the configuration without terminating the service:

1. Find the PID of the nginx master process (using ps aux or pgrep)pgrep -f nginx Output: 900 (nginx master process PID)2. Send SIGHUP signal (signal 1), restart nginx

kill -1 900

3. Verify if nginx is running normally (check process status)ps aux | grep nginx PID=900 still exists, indicating it has not terminated and has loaded the new configuration

Practical case 2: Use SIGTERM to gently terminate an abnormal process

If PID=1234 of the Java process is unresponsive, first attempt a gentle termination:

1. Confirm process information (to avoid mistakenly killing)ps aux | grep 1234 Confirm it is the abnormal Java process, not a system process2. Send SIGTERM signal (signal 15, default signal, can omit signal number)kill 1234 is equivalent to kill -15 12343. Wait 5-10 seconds, check if the process has terminatedps aux | grep 1234 If no output, it indicates termination; if there is still output, use the force signal

Practical case 3: Use SIGKILL to forcefully terminate a hung process

If SIGTERM cannot terminate the process with PID=1234, use signal 9 to force termination:

Send SIGKILL signal (signal 9)

kill -9 1234

Immediately check if the process has terminatedps aux | grep 1234 No output indicates it has been forcefully terminated

Practical case 4: Use pkill to batch terminate processes with the same name

Batch terminate all nginx processes (suitable for cleaning up old processes before restarting the service):

Use pkill to terminate all nginx processes by process name (send signal 15)

pkill -15 nginx

Verify if all have been terminatedps aux | grep nginx No output indicates all have been terminatedIf there are any remaining, use signal 9 to force termination

pkill -9 nginx

1. nice/renice: Adjust process priority (optimize resource allocation)

Core function: By