Linux Kill Command Cheat Sheet: 37 Examples for SOC Teams

Linux Kill Command Cheat Sheet: How SOC Analysts Safely Stop Processes During Incident Response

Quick Answer
The Linux kill command sends signals to processes, not just termination requests. Verify the PID first, try SIGTERM before SIGKILL, and remember that force-killing a suspicious process can destroy valuable forensic evidence.

Last verified: October 16, 2026

It is 2:14 a.m. and your monitoring dashboard lights up: a production Linux server is pinned at 100% CPU. A junior analyst, trying to be helpful, types pkill -9 python and hits Enter. The CPU drops, and so does the billing API, the log shipper, and a forensic lead. The "miner" turned out to be one of several Python processes on the box, and the one that mattered most is now gone, along with its memory contents.

That is the quiet danger of the kill family of commands. They are simple and fast, and they are unforgiving. This guide walks through kill, pkill, killall, and pgrep the way a SOC team actually uses them during Linux incident response: verify first, choose the right signal, and act with a plan.

Table of Contents

• What the kill Command Really Does
• Core Signals Every Analyst Should Know
• Verify Before You Terminate: Linux Process Monitoring Basics
• Using kill by PID
• pkill, pgrep, and killall: Targeting by Name
• Incident Response Workflow: Contain Without Destroying Evidence
• Common Mistakes That Cause Outages
• Expert Tips
• FAQ
• Conclusion

What the kill Command Really Does

Despite the name, kill does not kill anything by itself. It asks the kernel to deliver a signal to a process or process group. What happens next depends on the signal and on how the process handles it. A well-written service catches SIGTERM, flushes its buffers, closes its connections, and exits cleanly. Some signals cannot be caught at all, which is why they behave so differently in practice.

One more detail that trips people up: in most shells, kill is a built-in command, while /bin/kill is a separate binary. Their supported options can differ slightly, so check the documentation for your environment.

help kill

What it does: Displays help for your current shell's built-in kill. When to use it: Whenever you move between shells or distributions and are unsure which options are supported. Expected output: A short usage summary and list of options.

Core Signals Every Analyst Should Know

You do not need to memorize all of them. These cover almost every real situation:

Signal	Number (typical on Linux)	Practical meaning
SIGTERM	15	Polite request to terminate; the process can clean up. This is the default.
SIGKILL	9	Immediate termination; cannot be caught or ignored.
SIGHUP	1	Hangup; some services reload configuration when they receive it.
SIGINT	2	Interrupt, similar to pressing Ctrl+C in a foreground task.
SIGQUIT	3	Requests termination and may produce a core dump.
SIGSTOP	19	Suspends the process without terminating it.
SIGCONT	18	Resumes a stopped process.

Signal numbers can vary by architecture, so rely on names in scripts and runbooks. You can always check what your system uses:

kill -l
kill -l 9
kill -l TERM

What it does: The first command lists the signal names or numbers your shell supports. The second translates a number to a name (usually KILL), and the third translates a name to its number. When to use it: When reading old runbooks or logs that reference raw numbers. Expected output: A signal list, then KILL, then 15 on typical Linux systems.

Verify Before You Terminate: Linux Process Monitoring Basics

The single best habit in this entire article is to look before you act. PIDs are recycled by the system, similar process names are common, and a wrong guess on a production host is a self-inflicted incident. Start by finding what is consuming resources:

ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head

What it does: Lists the top CPU consumers with their PID, parent PID, owner, and command name. When to use it: At the start of any "high CPU" investigation. Expected output: A short table with the heaviest process at the top.

Then confirm exactly what you are about to touch:

ps -p 1234 -o pid,ppid,user,stat,comm,args

What it does: Shows the PID, parent, owner, state, command, and full arguments for PID 1234. When to use it: Right before sending any signal. Expected output: One row confirming that the process is the one you meant. Replace 1234 with your verified PID.

If you know the name but not the PID, preview with pgrep:

pgrep -a -x nginx
ps -p 1234 -f

What it does: The first line lists exact-name matches with their command lines. The second inspects the PID you identified. When to use it: Any time you plan to act on a process by name. Expected output: PIDs with full command lines, then a detailed view of one process.

Using kill by PID

The default signal is SIGTERM, so these two commands behave the same way:

kill 1234
kill -TERM 1234

What it does: Requests graceful termination of PID 1234. When to use it: First, almost always. Databases, web servers, and queue workers rely on this chance to shut down cleanly. Expected output: Nothing on success. An error such as "No such process" or "Operation not permitted" means the PID is gone or you lack permission.

After sending a signal, confirm the result instead of assuming it worked:

kill -TERM 1234
sleep 2
ps -p 1234 -o pid,stat,comm

What it does: Sends SIGTERM, waits two seconds, then checks whether the process still exists. Expected output: No matching row generally means the process is gone. If it still appears, it may be hung, handling the signal slowly, or ignoring SIGTERM.

When SIGTERM Is Not Enough

If a process ignores SIGTERM and you have confirmed it is safe to remove, you can escalate:

kill -9 1234

Warning: SIGKILL gives the process no chance to clean up. Unsaved data may be lost, lock files may be left behind, and temporary state is not removed. Use it as a last resort, not a habit. Expected output: None on success. Even SIGKILL cannot remove a process stuck in uninterruptible sleep (state D in ps) until the kernel operation it is waiting on completes.

Other Useful Signal Patterns

kill -s TERM 1234
kill --signal=TERM 1234
kill -HUP 1234
kill -TERM 1234 5678

These show the equivalent ways to name a signal, send SIGHUP, and signal several PIDs at once. Confirm in the service's documentation that SIGHUP means "reload configuration" before relying on it, because some programs treat it as a termination request.

kill -0 1234

What it does: Sends no actual signal; it only checks whether the process exists and whether you have permission to signal it. When to use it: Health checks in scripts. Expected output: No output and exit code 0 if the check succeeds.

sudo kill -TERM 1234

Use elevated privileges only when required and authorized. On shared enterprise systems, that usually means following your change or incident process rather than acting on instinct.

pkill, pgrep, and killall: Targeting by Name

Name-based tools are convenient and also the most common source of accidents. By default, pkill treats its argument as a pattern, so a short pattern can match more than you expect. Always preview first.

pgrep -a firefox

What it does: Lists matching PIDs and command lines without touching anything. Expected output: One line per match. If the list surprises you, stop.

pkill firefox
pkill -x firefox
pkill -u username firefox
pkill -P 1234
pkill -f 'python app.py'

What they do: In order, these send SIGTERM to processes matching the pattern, to processes whose names match exactly, to matching processes owned by one user, to direct children of PID 1234, and to processes whose full command line matches the pattern. When to use them: Use -x for precision, -u to limit scope, and -f when many processes share one interpreter name, as with several Python or Java services. Expected output: None on success.

pkill -9 firefox

Warning: This force-kills every matching process with no cleanup. Preview with pgrep -a first.

killall -TERM firefox
killall -KILL firefox

On Linux, killall signals processes by exact name. Be aware that on some other Unix systems, killall historically behaves very differently, so check killall --help on unfamiliar platforms.

sudo pkill -TERM -u username

Warning: This signals every process owned by that user, including their sessions and background jobs. Use it only when you intend to end the whole account's activity, such as during an authorized containment action.

Process Groups

kill -TERM -- -1234

The negative number targets process group 1234, which is useful when a parent launched several workers. Verify the group ID carefully, because the same command with the wrong number can reach far more processes than intended.

Incident Response Workflow: Contain Without Destroying Evidence

Here is where practitioners differ from tutorials. If a process looks malicious, an instant kill -9 feels satisfying, but it can erase what you need to understand the incident: its memory, its open network connections, and sometimes the path of its binary. A calmer sequence usually serves the investigation better, and should always follow your organization's incident response policy.

Step 1: Identify and record. Capture the details before anything changes.

ps -p 1234 -o pid,ppid,user,stat,lstart,args
ls -l /proc/1234/exe
tr '\0' ' ' < /proc/1234/cmdline

This records the owner, parent, start time, the executable path the process is running from, and its exact command line. A binary running from a temporary directory, or one whose file has been deleted, is worth flagging in your notes.

Step 2: Consider suspending rather than killing.

sudo kill -STOP 1234

SIGSTOP freezes the process without ending it, which halts activity while keeping its state available for your forensics team or EDR tooling. Resume it with kill -CONT only if you decide that is appropriate.

Step 3: Escalate to the right people. Many organizations want memory captured by trained responders or endpoint detection and response (EDR) tools before termination. Follow your playbook.

Step 4: Terminate gracefully, then forcefully if needed. Use SIGTERM, verify, and only then SIGKILL.

Step 5: Hunt for persistence. Killing a process does not remove how it started. Check scheduled jobs, systemd units, shell startup files, and SSH authorized keys, or the process will return after the next reboot or timer. This is the heart of effective threat hunting: the process is a symptom, and the launch mechanism is the cause.

Common Mistakes That Cause Outages

• Broad patterns: pkill java or pkill python on a shared host can take down unrelated services.
• Skipping the preview: Running pkill without pgrep -a first.
• Reaching for SIGKILL first: This skips cleanup and can leave corrupted state.
• Trusting a stale PID: Copying a PID from an old terminal window or ticket without rechecking it. PIDs get reused.
• Assuming signals fix the root cause: A respawning process usually means a service manager or attacker persistence is restarting it.
• Misreading zombies: A zombie process (state Z) is already dead and waiting for its parent to collect its exit status. Signaling it does nothing; the parent is the real target.

Expert Tips

• Make "pgrep -a first, then act" a team standard and put it in every runbook.
• Prefer pkill -x or -u over bare patterns to shrink the blast radius.
• Use exit codes in scripts: kill -0 is a clean way to test whether a PID is still alive.
• For managed services, use systemctl stop instead of raw signals so the service manager does not immediately restart the process.
• Document every termination in your ticket: PID, owner, command line, time, signal used, and why.
• Practice these commands in a lab VM, not on production hosts.
• No single technique guarantees containment; combine process controls with network isolation and account review.

Related Cybersecurity Topics You Should Explore

• Linux htop Command Cheat Sheet: Spot Hidden Threats in Seconds
  
• Linux top Command Cheat Sheet: Find Suspicious Processes Fast
  
• Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
  
• Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
  
• Linux findmnt Command: 43 Examples for Security Audits
  
• Linux tune2fs Cheat Sheet: 41 Commands, 4 Costly Mistakes
  
• Linux blkid Command: 41 Examples Every SOC Analyst Should Know
  
• Linux fsck Command Guide: Fix Disk Errors Without Data Loss
  
• Linux mkfs Command Cheat Sheet: Format Disks Safely (2026)
  
• Linux parted Command Cheat Sheet: Partition Disks Safely

FAQ

What is the difference between kill -15 and kill -9?

SIGTERM (15) asks a process to exit and lets it clean up. SIGKILL (9) forces immediate termination and cannot be caught or ignored.

What does kill -0 do?

It sends no real signal. It checks whether the process exists and whether you have permission to signal it.

Is pkill safe to use on production servers?

It can be, with care. Preview matches with pgrep -a, use exact matching with -x, and limit scope by user with -u.

Why does my process come back after I kill it?

A service manager, a parent process, or a scheduled task is likely restarting it. In a security context, this can also indicate persistence, so investigate how it launches.

Can SIGSTOP be ignored by a process?

No. Like SIGKILL, SIGSTOP cannot be caught or ignored, which is why it is useful for freezing a process during an investigation.

Why can't I kill some processes even with kill -9?

Processes in uninterruptible sleep (state D), often waiting on storage or hardware, will not exit until that operation completes. Zombie processes are already dead and must be reaped by their parent.

Conclusion

The kill family of commands looks like a basic Linux topic, but it is a daily decision point for SOC analysts and administrators. Verify the PID, choose the least aggressive signal that works, record what you saw, and remember that a dead process is not the same as a resolved incident. Handled carefully, these commands help you contain threats without causing outages or erasing evidence. Handled carelessly, they create the second incident the night is not ready for.

Analysis based on SOC monitoring experience and review of standard Linux documentation.