Linux pkill Command Cheat Sheet: 40 Safe Examples + pgrep Tips

Linux pkill Command Cheat Sheet: Safe Usage, pgrep Previews, and Detecting Abuse

Quick Answer
pkill sends signals to processes matched by name or attributes. Preview targets with pgrep first, prefer SIGTERM over SIGKILL, and monitor kill activity, because attackers also use it to stop security tools.

Last verified: October 18, 2026 (syntax checked against procps-ng behavior and the pkill manual page)

It is 2:07 a.m. and your SIEM raises a low-priority alert: the endpoint agent on a Linux web server has stopped reporting. Nobody patched it and nobody rebooted the host. When you pull the shell history, you find one short line that ran minutes earlier. It was a pkill command aimed at the process name of your security agent.

That is why pkill belongs in every SOC analyst's toolkit. Sysadmins use it daily for routine process control, and attackers use the same tool to quietly impair defenses. This guide covers both sides: how to use pkill and pgrep safely, which mistakes cause outages, and how to detect abuse in a Linux incident response workflow.

Table of Contents

• What pkill Actually Does
• Signals You Will Use Most
• Matching Processes: Name, Exact, and Full Command Line
• Filtering by User, Group, Parent, Terminal, and Session
• The Safe Workflow: Preview, Signal, Verify
• Danger Zone: sshd, Apache, and User-Wide Kills
• How Attackers Abuse pkill: Impair Defenses Detection
• Detection: Auditing Kill Activity on Linux
• Expert Tips from the SOC Floor
• FAQ
• Conclusion

What pkill Actually Does

pkill looks through the running process list, finds the processes that match your criteria, and sends each one a signal. The default signal is SIGTERM, which asks a process to shut down cleanly. It is part of the procps tool family alongside pgrep, which takes the same matching options but only lists matches instead of signaling them. That shared syntax is what makes the safe workflow below possible.

Two facts trip up newcomers. First, by default the pattern is a regular expression matched against the process name only, and it can match anywhere in that name. Second, the kernel stores that name in a field limited to 15 characters on Linux. Long executable names are truncated, so an exact match on the full name can silently fail. In that case, matching against the full command line (covered below) is the better approach.

Signals You Will Use Most

Signal	Effect	Typical use
SIGTERM (default)	Polite request to terminate; the process can clean up	First choice for almost everything
SIGKILL (-9)	Immediate kill; cannot be caught or handled	Last resort for hung processes
SIGHUP	Many daemons reload configuration	Reload behavior depends on the program
SIGINT	Same as pressing Ctrl+C	Interrupting foreground-style tools
SIGSTOP	Pauses a process (cannot be ignored)	Freezing a suspicious process
SIGCONT	Resumes a stopped process	Undoing SIGSTOP

You can specify a signal by name or number. These forms are equivalent ways to send SIGTERM:

pkill firefox
pkill -SIGTERM firefox
pkill --signal SIGTERM firefox

What it does: asks every process whose name contains "firefox" to exit gracefully. Expected output: none on success. pkill is silent unless you add -e.

Warning: SIGKILL skips all cleanup. Databases can leave corrupted state, temp files stay behind, and child processes may be orphaned. Use it only after SIGTERM has failed.

pkill -9 firefox
pkill -KILL firefox

Both commands send SIGKILL. Use them sparingly.

Pause and resume instead of killing

pkill -STOP firefox
pkill -CONT firefox

The first command freezes matching processes in place and the second resumes them. In incident response, pausing is often smarter than killing, as explained in the expert tips below.

Other signals in practice

pkill -HUP nginx
pkill -INT firefox

A caution on -HUP nginx: the pattern also matches worker processes, not just the master. For a configuration reload, systemctl reload nginx or nginx -s reload is cleaner and more predictable.

Matching Processes: Name, Exact, and Full Command Line

pkill -i chrome
pkill -x firefox
pkill 'firefox.*'

• -i ignores case, so "Chrome" and "chrome" both match.
• -x requires the pattern to match the entire process name exactly. This is the safest way to avoid hitting look-alike names.
• A quoted pattern such as 'firefox.*' is treated as a regular expression. Always quote patterns so your shell does not expand special characters first.

Lines such as pkill -x nginx and pkill -x firefox do the same job on different targets: they match only processes named exactly that.

Matching the full command line with -f

Many scripts and interpreters share a generic process name such as python or bash. The -f option matches against the whole command line, so you can target one specific script:

pkill -f 'python script.py'
pkill -f 'python.*script\.py'

The second form uses a regular expression, where \. matches a literal dot. This is more precise than letting the dot match any character.

Gotcha: -f patterns can match more than you expect, including a wrapper shell whose own command line contains your pattern text. That is another reason to preview first.

Filtering by User, Group, Parent, Terminal, and Session

Name matching is only one dimension. These filters narrow or widen the target set:

Option	Matches
-u bob	Effective user ID or name
-U bob	Real user ID or name
-G developers	Real group ID or name
-g 1234	Process group ID (not the same as real group ID)
-P 1234	Parent process ID
-t pts/2	Controlling terminal
-s 1234	Session ID
-n / -o	Newest / oldest matching process only

Note: many cheat sheets describe -g as "real group ID." In procps-ng it refers to the process group. Real group matching is -G. Mixing them up can send a signal to a completely different set of processes.

pkill -u bob
pkill -G developers firefox
pkill -P 1234
pkill -t pts/2
pkill -n firefox
pkill -o firefox

You can combine filters. For example, pkill -G developers firefox only signals Firefox processes owned by that group, which is far safer than a bare name match on a shared server.

The Safe Workflow: Preview, Signal, Verify

The single best habit for production systems is a three-step loop. pgrep accepts the same matching options as pkill, so what you preview is what you will hit.

# 1. Preview: -a shows PID plus full command line
pgrep -a -f 'python script.py'

# 2. Signal, only if the preview shows the right targets
pkill -TERM -f 'python script.py'

# 3. Verify what remains
pgrep -a -x firefox

Expected output of step 1: one line per match, such as a PID followed by its command. If you see anything unfamiliar, stop and refine the pattern.

More useful previews:

pgrep -a -u bob
pgrep -a -x firefox
pgrep -a -P 1234
pgrep -x firefox

The last command is a quick existence check. It prints matching PIDs and returns exit status 0 if at least one process matched.

Checking exit status and echoing kills

pkill -TERM firefox
echo $?

Per the manual page, exit status 0 means at least one process matched, 1 means none matched, 2 means a syntax error, and 3 means a fatal error. Note that status 0 means a match and a signal attempt, not proof that the process exited. Always verify afterward.

pkill -e -TERM firefox

The -e flag echoes the name and PID of each process signaled. It is supported on current procps-ng builds, but check pkill --help on older or minimal systems.

pkill --help
man pkill

Always check the local manual page. Options differ slightly between procps-ng, BSD, and BusyBox implementations.

Inspect before you act on a service

ps -eo pid,ppid,user,stat,comm,args | grep '[n]ginx'

This lists the PID, parent PID, owner, state, name, and full arguments for nginx processes. The [n]ginx bracket trick stops grep from matching its own process line. The PPID column shows you which process is the master and which are workers.

Danger Zone: sshd, Apache, and User-Wide Kills

Warning: the commands in this section can lock you out of a server or end every session for a user. Test on a lab machine and keep console access available.

sudo pkill -TERM -x sshd
sudo pkill -TERM -x apache2
sudo pkill -TERM -u bob

• sshd: an exact match on sshd hits the listener and the per-connection processes, which can terminate your own remote session. If you are connected over SSH, you may lose access with no way back in. For a configuration change, use systemctl reload ssh (the service is named sshd on some distributions), and run sshd -t first to validate the config.
• apache2: signaling every matching process bypasses the service manager's graceful handling. Prefer systemctl reload apache2 or systemctl restart apache2.
• -u bob: this signals everything the user owns, including their login shell. That is useful when disabling a compromised account during an incident, but disruptive if used by mistake.

After any service signal, re-inspect with pgrep -a -x sshd to confirm the expected state.

How Attackers Abuse pkill: Impair Defenses Detection

Once an intruder gains a shell, one of the early moves is often to blind the defenders. MITRE ATT&CK catalogs this behavior as Impair Defenses: Disable or Modify Tools (T1562.001), and stopping services falls under Service Stop (T1489). On Linux, a process-signaling command is the easiest way to do it, because it requires no special malware, just a built-in utility.

From a defender's perspective, the pattern to look for is not pkill itself, which is legitimate and common. It is the combination of factors:

• A kill targeting the name of a security agent, logging daemon, or monitoring process
• Execution by an unexpected user, from an unusual parent process, or at an odd hour
• A kill that closely precedes a gap in telemetry from that host
• Repeated kill attempts that suggest a script retrying after an agent self-heals

Mature endpoint detection and response (EDR) platforms ship tamper protection for exactly this reason, but anything running without it, or configured loosely, remains exposed. Treat a silent agent as a potential incident, not a networking glitch, until proven otherwise.

Detection: Auditing Kill Activity on Linux

Two inexpensive data sources give you strong coverage: command execution logging and syscall auditing. With the Linux Audit framework, you can record signal-sending system calls:

sudo auditctl -a always,exit -F arch=b64 -S kill -S tkill -S tgkill -k kill_signals

What it does: logs every kill-family syscall on 64-bit systems under the key kill_signals. Expected output: none at the command line. Search later with:

sudo ausearch -k kill_signals -i

Because this rule can generate heavy volume on busy systems, consider filtering by user or limiting it to specific targets after baselining. To persist the rule across reboots, add it to a file under /etc/audit/rules.d/. Pair it with execve auditing so you can see the actual command line, not just that a signal was sent.

For SOC teams, useful correlation ideas include:

• Alert when a kill signal is sent to a process owned by a security tool
• Alert when an agent heartbeat stops within minutes of a kill event from a non-admin session
• Review shell history and authentication logs for the same session

Forward these logs off-host. An attacker with root can tamper with local logs, but not with copies that already reached your SIEM.

Expert Tips from the SOC Floor

• Freeze, do not kill, suspicious processes first. A killed process loses its memory state. Sending SIGSTOP pauses it while you collect evidence such as ls -l /proc/PID/exe and its open files. Once captured, you can decide to terminate.
• Use -x by default. Exact matching eliminates most accidental collateral damage.
• Prefer the service manager for services. systemctl understands dependencies and restarts; raw signals do not.
• Beware the 15-character name limit. If an exact match returns nothing for a long name, check with pgrep -a -f instead.
• Do not run pkill -f from a wrapper script that contains the same pattern in its own arguments. You can end up signaling the wrapper.
• Watch masquerading. Malware often renames itself to look like a system process. Name-based matching alone is not proof of legitimacy, so check the executable path.
• Document before you terminate. In an incident, record the PID, user, parent, and command line first.

Related Cybersecurity Topics You Should Explore

• Linux Kill Command Cheat Sheet: 37 Examples for SOC Teams
  
• 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

FAQ

What is the difference between pkill and kill?

kill needs a PID. pkill finds processes by name or attributes and signals all matches, which is convenient but riskier.

What signal does pkill send by default?

SIGTERM (signal 15), a polite request to terminate that the process can handle for cleanup.

Is pkill -9 safe?

It works, but SIGKILL prevents cleanup and can leave corrupted data or orphaned children. Use SIGTERM first and escalate only if needed.

How do I see what pkill will kill before running it?

Run pgrep -a with the same options. It lists the matching PIDs and command lines without signaling anything.

Why did pkill not stop my process?

Common causes: the process name was truncated at 15 characters, the process belongs to another user (you need sudo), or the program is ignoring SIGTERM. Check with pgrep -a -f and echo $?.

Can pkill be used to disable security tools?

Yes. Any user with sufficient privileges can signal a security agent, which is why tamper protection, audit logging, and heartbeat monitoring matter.

Conclusion

pkill is a small command with outsized consequences. Used carefully, it is a fast, precise way to manage runaway processes. Used carelessly, it can drop your own SSH session or take down a production service. Used maliciously, it can quietly blind your defenses. The habits that protect you are simple: preview with pgrep -a, match exactly with -x, start with SIGTERM, verify afterward, and audit signal activity so that the next quiet agent is a lead, not a mystery.

Analysis based on SOC monitoring and public documentation review (procps-ng manual pages and MITRE ATT&CK).