Guide to Understanding Linux Process Management with 'ps' and 'kill'

Managing Linux processes is a daily troubleshooting skill. When an app hangs, a backup job eats CPU, or a daemon needs a clean restart, ps helps you find the process and kill lets you send it the right signal.

Every running program has a process ID, or PID. Once you know that PID, you can inspect ownership, parent processes, CPU and memory use, and decide whether to ask the process to stop cleanly or force it down as a last resort.

The Linux Process Model: PIDs and States

In Linux, every running program, service, or task is treated as a process. Each process is uniquely identified by a Process ID (PID), a positive integer assigned by the kernel upon creation. This PID is the primary way system tools reference and manipulate a specific process.

Processes move through states such as running, sleeping, stopped, and zombie. A sleeping process is usually waiting for I/O or another event. A zombie has already exited, but its parent process has not collected its exit status.

Viewing Processes with the ps Command

The ps (process status) command is used to display information about currently running processes. Because the output can be overwhelming, different options are used to select which processes to display and which information columns to include.

Essential ps Syntax and Flags

There are two primary styles for ps flags: Unix style (prefixed with -) and BSD style (no prefix). Modern practice often favors combining Unix-style flags for comprehensive views.

1. Viewing All Processes (BSD Style)

The most common command for a system overview is ps aux.

• a: Show processes for all users.
• u: Display processes in a user-oriented format (showing user, CPU usage, memory usage, etc.).
• x: Include processes that do not have a controlling terminal (like background daemons).

ps aux

2. Viewing Processes in a Standard Format (UNIX Style)

The ps -ef command provides a full listing in a POSIX-style format.

• -e: Select all processes.
• -f: Display the full-format listing, including PPID and command arguments.

ps -ef

Interpreting Key Output Columns

Regardless of the flags used, certain columns are critical for process management:

Column	Description
PID	Process ID (the unique identifier)
PPID	Parent Process ID (the PID of the process that started this one)
USER	The user who owns the process
%CPU	Percentage of CPU time used
%MEM	Percentage of physical memory used
VSZ	Virtual memory size (in KiB)
RSS	Resident Set Size (physical memory used, in KiB)
STAT	Current state of the process (e.g., R=Running, S=Sleeping, Z=Zombie)
COMMAND	The command that started the process

Filtering Processes with grep

To find a specific process, you can pipe ps to grep.

For example, this looks for Apache httpd processes:

ps aux | grep httpd

Tip: ps | grep often shows the grep process itself. Bracket notation avoids that extra match:

ps aux | grep '[h]ttpd'

Managing Processes with the kill Command

The kill command doesn't just stop processes; it sends signals to them. The default behavior is to request a graceful termination, but other signals can instruct a process to reread configuration files, halt execution temporarily, or force an immediate exit.

Understanding Signals

Signals are standardized numeric or mnemonic codes. You can list available signals using kill -l.

Signal Name	Signal Number	Description
SIGTERM	15	The default termination signal. Asks the process to shut down gracefully.
SIGKILL	9	The immediate, forceful termination signal. The process cannot ignore this.
SIGHUP	1	Hangup signal, often used by daemons to reread configuration files.
SIGSTOP	Usually 19 on x86 Linux	Stops (pauses) a process without terminating it.
SIGCONT	Usually 18 on x86 Linux	Resumes a stopped process.

Sending Signals with kill

The basic syntax for the kill command is:

kill -SIGNAL PID

1. Graceful Termination (The Best Practice)

Try SIGTERM first. It gives the application a chance to save state, close files, finish requests, and release locks.

kill 12345  # Defaults to SIGTERM (15)
# OR
kill -15 12345

2. Forceful Termination (Last Resort)

If a process is unresponsive and ignores SIGTERM, use SIGKILL (signal 9). This stops the process without application-level cleanup. That can leave partial writes, abandoned lock files, or interrupted transactions depending on what the process was doing.

kill -9 12345

Managing Processes by Name: pkill and killall

While ps and kill rely on PIDs, sometimes it's faster to target processes by name. Use these commands with extreme caution, as they can affect multiple processes simultaneously.

killall

Terminates all processes matching the exact process name provided.

killall httpd  # Sends SIGTERM to all processes named 'httpd'
killall -9 cron  # Forcefully kills all 'cron' processes

pkill

Allows for pattern matching (regex) when selecting which processes to signal, offering more flexibility than killall.

# Kills any process whose full command line contains 'firefox'
pkill -f firefox

Warning on killall and pkill: If you accidentally target a critical system process (like init or systemd), you can destabilize or crash your entire operating system. Always verify the target PID using ps before using killall or pkill with broad patterns.

A Safe Process Management Workflow

When troubleshooting a runaway application, follow this systematic approach:

1. Identify: Use ps aux | grep <process_name> to find the process PID and verify its status.
2. Check State: Examine the STAT column. If it is Z, the process is already dead; you need the parent process to reap it. Check the PPID before killing anything.
3. Attempt Graceful Stop: Send SIGTERM (default kill PID). Wait a few seconds.
4. Verify Stop: Run ps again.
5. Force Stop If Needed: If the process persists and you understand the risk, send SIGKILL with kill -9 PID.

The practical habit is simple: identify the PID, check the owner and state, send the gentlest useful signal, then verify the result. That keeps process cleanup predictable and reduces the chance of stopping the wrong workload.