Linux Process Management Cheat Sheet: ps, top, kill & More

Linux Process Management Commands: ps, top, htop, kill, nice and Job Control Cheat Sheet for SOC Analysts

Quick Answer
Linux process management commands such as ps, top, htop, kill, pkill, killall, nice, renice, and job control let you find, inspect, prioritize, and stop processes. Investigate suspicious ones before terminating them.

Last verified: October 13, 2026

It is 2:07 a.m. and the pager goes off. A customer-facing web server shows a load average of 40, and the only ticket says "site is slow." Nothing in the application logs looks wrong. Then you SSH in, run one command, and see an unfamiliar process called kworker-update eating 380% CPU. Real kernel workers show up in brackets and do not run from /tmp.

This is a composite scenario based on common patterns, not a specific named incident.

That moment is why Linux incident response starts with process management. Before any EDR dashboard or SIEM query, the fastest ground truth on a Linux host is what is running, who started it, and what it is doing. This guide covers ps, top, htop, kill, pkill, killall, nice, renice, jobs, bg, and fg from a defender's point of view, with a cheat sheet at the end.

Table of Contents

• Why Process Management Is a Security Skill
• ps: Taking a Snapshot of the System
• top and htop: Live Process Monitoring
• Investigating a Suspicious Process Before You Kill It
• kill, pkill, and killall: Stopping Processes Safely
• nice and renice: Controlling Priority
• Job Control: jobs, bg, fg
• Quick Reference Cheat Sheet
• Detection and Prevention for SOC Teams
• Expert Tips
• FAQ
• Conclusion

Why Process Management Is a Security Skill

Almost every post-compromise activity ends up as a process: a cryptominer, a reverse shell, a persistence script, a data-staging job. MITRE ATT&CK tracks this under techniques such as Process Discovery (T1057), Masquerading (T1036), and Resource Hijacking (T1496). Defenders who read the process table well can spot the oddities that automated tooling sometimes misses.

Process management is also an operational skill. The same commands that help you hunt a miner also help you stop a runaway backup job from starving a production database. Learn them once and you will use them in both roles.

ps: Taking a Snapshot of the System

ps prints a point-in-time view of processes. It is the best tool for scripting and for evidence you want to paste into a ticket.

Common ps forms

ps aux
ps -ef
ps -eo pid,ppid,user,etime,%cpu,%mem,cmd --sort=-%cpu | head -15
ps -p 1234 -o pid,ppid,user,lstart,cmd
ps auxf

What they do: ps aux (BSD style) and ps -ef (System V style) list every process on the system. The custom -eo form picks your own columns and sorts by CPU usage. -p inspects one PID, and lstart shows its exact start time. auxf adds an ASCII process tree.

When to use them: use the sorted form for fast triage. Use -p with lstart to line up a process start time against log timestamps, such as a login or a file upload.

Expected output: a table of PIDs, parent PIDs (PPID), owners, elapsed time, CPU and memory percentages, and the full command line.

Pay attention to three columns:

• PPID: a web server user (www-data, apache, nginx) spawning an interactive shell is worth investigating.
• TTY: a ? means no controlling terminal. That is normal for daemons but notable for unfamiliar names.
• CMD: names in square brackets are kernel threads. A "kernel thread" name without brackets, or one running from a user-writable path, is suspicious.

top and htop: Live Process Monitoring

top ships with virtually every Linux distribution, which makes it dependable on locked-down servers where you cannot install anything. htop is a friendlier alternative that usually needs a package install.

top
top -u www-data
top -p 1234
top -b -n 1 | head -20

The last form runs in batch mode, which is useful for capturing one snapshot into a file or a ticket.

Useful interactive keys in top

• P sorts by CPU and M sorts by memory
• 1 toggles a per-CPU view
• c shows the full command line instead of just the name
• u filters by user
• k kills a process (prompts for PID and signal)
• r renices a process
• q quits

htop essentials

sudo apt install htop      # Debian / Ubuntu
sudo dnf install htop      # RHEL / Fedora family
htop

In htop, press F5 (or t) for tree view, F3 to search, F4 to filter, F6 to change the sort column, F7/F8 to lower or raise the nice value, and F9 to send a signal. The tree view is especially valuable: a clean parent-to-child chain makes unexpected process lineage obvious.

Investigating a Suspicious Process Before You Kill It

The instinct is to terminate the odd process immediately. Resist it. Killing a process destroys volatile evidence: its memory, open files, and network connections. Take a minute to capture context first. The /proc filesystem exposes most of what you need.

ls -l /proc/1234/exe
ls -l /proc/1234/cwd
tr '\0' ' ' < /proc/1234/cmdline; echo
sudo ls -l /proc/1234/fd
sudo lsof -p 1234
sudo ss -tnp | grep 1234

What they reveal:

• /proc/PID/exe is a symlink to the running binary. If it ends in (deleted), the file was removed from disk after launch, a pattern defenders treat as a strong lead.
• /proc/PID/cwd shows the working directory, often /tmp or /dev/shm for unwanted processes.
• /proc/PID/cmdline is the full command line with null separators, which the tr command makes readable.
• lsof and ss show open files and network connections tied to that PID.

To sweep the whole host for processes running from commonly abused locations or with deleted binaries:

sudo ls -l /proc/*/exe 2>/dev/null | grep -E '/tmp|/dev/shm|\(deleted\)'

Legitimate software occasionally trips this check, such as a package update that replaced a binary while the old process kept running. Treat hits as leads to verify, not verdicts.

If your policy allows it, preserve a copy of the binary for analysis in an isolated environment and never run it:

sudo mkdir -p /root/evidence
sudo cp /proc/1234/exe /root/evidence/pid1234.bin
sudo sha256sum /root/evidence/pid1234.bin

If you need time to think without letting the process keep working, you can pause it instead of killing it. We cover that with signals in the next section.

kill, pkill, and killall: Stopping Processes Safely

Despite the name, kill sends signals. Terminating is just the default use. List the available signals with kill -l.

kill 1234              # SIGTERM: polite request to exit
kill -SIGSTOP 1234     # pause the process (preserves its state)
kill -SIGCONT 1234     # resume a paused process
kill -HUP 1234         # often used to reload configuration
kill -9 1234           # SIGKILL: forced, cannot be caught

Warning: kill -9 gives the process no chance to clean up. It can leave temporary files, locks, and half-written data behind, and on a database or other stateful service it can cause corruption or a long recovery. Try plain kill first, wait a few seconds, and escalate only if needed. Never kill PID 1 or critical system services on a production host without a change plan.

pkill and pgrep: matching by name or attribute

pgrep -af miner
pkill -x processname
pkill -u username
pkill -t pts/2

Always run pgrep -af with your pattern first. It shows exactly which processes would match, using the same matching rules as pkill. A loose pattern can match more than you intended. -x requires an exact name match, -u targets a user, and -t targets a terminal, which is handy when containing an unauthorized interactive session.

killall: by name

killall processname
killall -i processname
killall -u username processname

-i prompts before each kill. Caution: on Linux, killall signals processes by name. Historically on some other Unix systems it meant something far more drastic, so avoid reflexively using it on unfamiliar platforms.

nice and renice: Controlling Priority

The nice value ranges from -20 (highest priority) to 19 (lowest). The default is usually 0. It is a scheduling hint, not a hard limit, but it is very useful for containing resource-hungry work without killing it.

nice -n 10 ./long_running_script.sh
renice -n 15 -p 1234
sudo renice -n -5 -p 1234
ps -o pid,ni,cmd -p 1234

What they do: nice starts a command at a chosen priority, and renice changes it for a running process. Regular users can only make their own processes nicer (raise the value), while lowering the value requires root.

Defensive use case: during an investigation you may not be allowed to stop a suspicious process yet, because of change windows or business sign-off. Reniceing it to 19 can protect the services next to it while the case moves forward. Use ionice as well if disk contention is the issue.

Job Control: jobs, bg, fg

Job control manages processes started from your current shell session. It is easy to forget until you need it during a long SSH session.

sleep 300 &
jobs -l
# press Ctrl+Z to suspend a foreground job
bg %1
fg %1
kill %1
disown -h %1

How it works: a trailing & starts a job in the background. Ctrl+Z suspends the foreground job, bg resumes it in the background, and fg brings it back. %1 refers to job number 1 from jobs. disown -h keeps a job from receiving SIGHUP when the shell exits, much like nohup.

Security angle: background jobs, nohup, and disown are normal admin tools, but they also explain why a process can outlive an SSH session. When you find a long-running process with no TTY and a parent PID of 1 that you cannot match to a service, check how it got there by reviewing shell history, auth logs, and the process start time.

Quick Reference Cheat Sheet

Command	Purpose	Example
ps	Snapshot of processes	ps aux
top	Live process view	top -u www-data
htop	Interactive viewer with tree mode	htop
kill	Send a signal to a PID	kill -SIGSTOP 1234
pkill / pgrep	Match processes by pattern	pgrep -af pattern
killall	Signal by exact name	killall -i name
nice	Launch at a set priority	nice -n 10 cmd
renice	Change running priority	renice -n 15 -p 1234
jobs	List shell jobs	jobs -l
bg / fg	Resume in background / foreground	bg %1, fg %1

Detection and Prevention for SOC Teams

Manual process checks are the starting point. To scale them, build detection around the same signals.

Detection ideas

• Process lineage: alert when web server or database service accounts spawn shells or network utilities.
• Execution from writable paths: flag binaries launched from /tmp, /var/tmp, or /dev/shm.
• Sustained high CPU: unexplained, long-lived CPU saturation is a classic sign of cryptojacking.
• Name masquerading: processes that imitate kernel threads or system daemons but run from unexpected paths.

For command-level visibility, Linux auditing can record process execution:

sudo auditctl -a always,exit -F arch=b64 -S execve -k exec_log
sudo ausearch -k exec_log --start today | tail -50

This rule is noisy on busy servers. Test it in staging, forward the logs to your SIEM, and tune it before turning it on widely. Many endpoint detection and response platforms and open-source agents also collect the same process telemetry with less manual tuning.

Prevention and hardening

• Mount /tmp and /dev/shm with noexec where your workloads allow it.
• Apply least privilege to service accounts so a compromised app cannot spawn arbitrary tools.
• Use systemd sandboxing options and resource limits (cgroups) to cap what a service can consume.
• Patch promptly and review SSH access, since many process-level incidents start with valid credentials or an exposed service.
• Align your Linux server hardening baseline with a recognized framework such as the CIS Benchmarks or NIST guidance.

No single control stops every attack, so layer these defenses and test them regularly.

Expert Tips

• Snapshot first. Save ps and top -b -n 1 output with timestamps before changing anything.
• Pause, then decide. SIGSTOP freezes a process without discarding its memory. Use it when you need to think or capture memory, and remember it also stops legitimate work.
• Preview every pattern. Run pgrep -af before every pkill.
• Do not trust names. Verify the executable path, hash, and parent. A name proves nothing.
• Check persistence after you kill. If it comes back, look at cron, systemd units, and shell startup files.
• Containers add a layer. A process visible on the host may belong to a container, so check namespaces and container runtime tools before you act.
• Document your actions. Write down who killed what, when, and why, because incident timelines depend on it.

Related Cybersecurity Topics You Should Explore

• 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
  
• Linux fdisk Command Cheat Sheet: Partition Disks Safely (2026)
  
• Linux lsblk Command: Cheat Sheet for Disks, USB & Encryption
  
• Linux umount Command Cheat Sheet: Safe Unmount Without Data Loss
  
• Linux Mount Commands Cheat Sheet: Secure Mounts (2026)

FAQ

What is the difference between kill, pkill, and killall?

kill targets a specific PID or job. pkill matches processes by pattern or attributes such as user or terminal. killall targets processes by exact name.

Is kill -9 safe to use?

It is a last resort. SIGKILL cannot be handled by the process, so no cleanup occurs. Try SIGTERM first and escalate only if the process ignores it.

What is the difference between top and htop?

top is almost always preinstalled and works anywhere. htop adds a tree view, mouse support, and easier filtering, but typically needs installing.

How do I find out what a suspicious process is doing?

Inspect /proc/PID/exe, cwd, and cmdline, then review open files with lsof and network connections with ss. Do this before terminating it so the evidence survives.

Can I lower a process's nice value without root?

No. Regular users can only raise the nice value (lower priority) of their own processes. Lowering it, which means higher priority, requires root privileges.

How do I keep a job running after I close my SSH session?

Use nohup when launching it, or run disown -h %N after backgrounding it. For anything long-lived, a systemd service or terminal multiplexer is more reliable.

Conclusion

Back at 2:07 a.m., the difference between a messy night and a clean investigation is discipline: list, inspect, capture, contain, and only then terminate. Master ps, top, and htop to see the host, /proc to understand it, kill, pkill, and killall to act on it, and nice, renice, and job control to manage it without collateral damage. Practice these commands on a test VM until they are muscle memory, because during a real incident you will not want to read a man page.

Analysis based on SOC monitoring experience and public vendor and framework documentation.