# Process management on Linux: ps, top, kill, and friends
Source: https://vpsdime.com/knowledgebase/technical-questions/process-management
Last reviewed: 2026-07-02
Summary: The complete toolkit, seeing processes (ps, top, htop), finding them (pgrep, pidof, lsof), signals and what kill actually does (TERM vs KILL, and why -9 is the last resort), pkill and killall, priorities with nice and renice, and the shell's own job control (&, Ctrl+Z, fg, bg, jobs, disown).

## What this is

Everything running on your VPS is a **process** with a numeric **PID**, and this is the toolkit for seeing them, finding them, stopping them, and re-prioritizing them, the vocabulary the [slow-VPS](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps) and [keep-it-running](https://vpsdime.com/knowledgebase/technical-questions/keep-apps-running-after-ssh) guides assume.

## Seeing: ps, top, htop

- **`ps aux`** is the census, every process, its user, PID, CPU/memory share, and command line. Nobody reads it raw; it gets piped: `ps aux --sort=-%cpu | head` (the hungriest), `ps aux | grep nginx` (one program's processes).
- **`top`** is the live view, on every machine ever. **`htop`** (`apt install htop`) is the one you'll actually enjoy: colors, scrolling, a tree view (`F5`, who spawned whom, great for [cron pileups](https://vpsdime.com/knowledgebase/troubleshooting/cron-not-running)), sort by clicking columns, and kill from inside (`F9`).

## Finding: pgrep, pidof, lsof

- **`pgrep -a nginx`**, PIDs (and command lines) matching a name; `pgrep -u www-data` by user. **`pidof nginx`** is the terser classic for exact names.
- **`lsof`** answers "who has this *thing* open": `lsof -i :8080` (which process owns this **port**, the sibling of [`ss -tulnp`](https://vpsdime.com/knowledgebase/getting-started/securing-public-services)), `lsof /var/log/big.log` (who's writing this file), `lsof +L1` ([the deleted-but-held disk mystery](https://vpsdime.com/knowledgebase/troubleshooting/disk-full)).

## Stopping: signals, and what kill really does

`kill` doesn't kill, it **delivers a signal**, and which one matters:

- **`kill <pid>`** sends **SIGTERM** (15): "please shut down." The process gets to close files, flush buffers, and exit cleanly. **Always first.**
- **`kill -9 <pid>`** sends **SIGKILL**: the kernel removes the process, no cleanup, no goodbye. Databases mid-write, half-written files, orphaned locks, this is why `-9` is the *last* resort, not the reflex. The discipline: TERM, wait five seconds, then KILL if it ignored you.
- **`kill -HUP <pid>`**, many daemons treat SIGHUP as "reload your config" (though for systemd services, `systemctl reload` is the proper spelling).

By name instead of PID: **`pkill nginx`** (pattern, same matching as pgrep, and `pkill -u baduser` for everything a user runs) and **`killall nginx`** (exact name). Both accept `-9` with the same warning attached. And for anything that's a *service*, prefer `systemctl stop`, killing a unit's process behind systemd's back just triggers its `Restart=` policy, [which you may have set yourself](https://vpsdime.com/knowledgebase/troubleshooting/services-not-starting-after-reboot).

A footnote you'll meet eventually: a **zombie** (`Z` state, `<defunct>`) is already dead, just unreaped by its parent, it holds no resources and can't be killed harder; a *crowd* of zombies points at a buggy parent process.

## Prioritizing: nice and renice

Covered fully in [the CPU-limiting guide](https://vpsdime.com/knowledgebase/technical-questions/limit-cpu-usage), the short form: `nice -n 19 <command>` starts a job at lowest priority (uses idle CPU, yields to everything), `renice 19 -p <pid>` demotes one already running, and `ionice -c3` is the disk-I/O sibling.

## The shell's own job control: &, Ctrl+Z, fg, bg

Within one terminal session, the shell manages **jobs**:

- `command &` starts it in the background; **Ctrl+Z** suspends the foreground job; **`bg`** resumes the suspended job in the background, **`fg`** brings it back; **`jobs`** lists them (`fg %2` by number).
- The catch: jobs belong to the session, close it and they die. `disown -h %1` after `bg` is [the rescue for a job you should have started in tmux](https://vpsdime.com/knowledgebase/technical-questions/keep-apps-running-after-ssh), which remains the real answer for anything long.

## The recipes

```
ps aux --sort=-%mem | head          # what's eating memory
lsof -i :3306                       # what owns this port
pkill -f runaway-script.sh          # stop every instance by pattern (-f matches full command line)
kill 1234 && sleep 5 && kill -9 1234 2>/dev/null    # polite, then firm
```

And when a process you don't recognize tops every list, [that's a different guide](https://vpsdime.com/knowledgebase/troubleshooting/compromised-vps-recovery).

## Still need help?

You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning:

- the VPS hostname or IP,
- the process (name or PID) and what you're trying to do with it.

## Related questions

- "How do I see and sort running processes?"
- "What's the difference between kill and kill -9?"
- "How do I find which process is using a port?"
- "What's a zombie process and should I worry?"
- "What do fg, bg, and Ctrl+Z do?"