5.2 Managing Processes

Viewing Processes: ps, top, htop

Every running program is a process with a process ID (PID), a parent PID (PPID), an owner, and a state. The two ps invocations you must distinguish for the exam come from different Unix traditions:

ps aux     # BSD style: ALL users' processes, with %CPU, %MEM, TTY, STAT
ps -ef     # System V style: full-format listing of every process with PPID

With ps aux, the columns you read most are USER, PID, %CPU, %MEM, STAT (R running, S sleeping, Z zombie, T stopped), and COMMAND. With ps -ef, the PPID column makes it easy to trace parent-child relationships. Add pipes to filter: ps aux | grep nmap or use the purpose-built pgrep nmap, which prints just the matching PIDs (pgrep -u kali -a lists all of a user's processes with their command lines). For a live view, top refreshes a sorted process table — press M to sort by memory, P by CPU, k to kill by PID. htop is the friendlier, color, mouse-aware alternative with a tree view (F5) and per-core bars, though it is an optional install rather than a guaranteed default.

Signals and kill

kill is badly named: it sends a signal to a PID, and termination is only one possibility. The exam expects you to know at least these three:

kill 1234              # sends SIGTERM (15) to PID 1234
kill -9 1234           # SIGKILL — last resort, uncatchable
kill -HUP 1234         # tell a daemon to reload configuration
kill -l                # list all signal names and numbers

Best practice is always TERM first, KILL only if the process ignores it. pkill and killall signal by name instead of PID: pkill -9 nmap kills every process whose name matches; pkill -u kali targets all of a user's processes. The companion pgrep -a nmap is the safe way to preview what pkill would hit. Watch out: killall on some Unix systems (not Linux) kills everything — on Kali it is name-based, but the exam may test the distinction.

Job Control: Foreground, Background, Suspend

Each interactive shell tracks its own jobs. You control them without PIDs:

nmap -sS 10.0.0.0/24 &     # trailing & — launch directly in the background
# ...a long scan runs in the foreground instead:
# press Ctrl-Z             # SIGTSTP — suspends the job, returns your prompt
jobs                       # [1]+ Stopped   nmap -sS 10.0.0.0/24
bg %1                      # resume job 1 in the background
fg %1                      # pull job 1 back to the foreground
kill %1                    # signal a job by its job number, not PID

Ctrl-Z suspends (it does not kill); bg resumes the suspended job in the background; fg brings a background job forward; jobs lists them with their numbers. Ctrl-C sends SIGINT to the foreground job. Remember that jobs are tied to the shell that started them — log out, and the shell sends SIGHUP to its jobs, killing them.

Surviving Logout: nohup and disown

For a long scan or listener that must outlive your SSH session, use nohup:

nohup ./long-scan.sh > scan.log 2>&1 &

nohup makes the command ignore SIGHUP; with no redirect it appends output to nohup.out. If the job is already running, disown %1 removes it from the shell's job table so no SIGHUP is ever sent. (The more modern answer is a terminal multiplexer like tmux or screen, which Kali ships — but nohup is the classic exam answer.)

Priorities: nice and renice

CPU scheduling priority is steered by the nice value, from -20 (highest priority) to +19 (lowest); the default is 0. Regular users can only raise their niceness (be nicer to others); only root can assign negative values.

nice -n 10 ./crack.sh &      # start with nice +10 — yields CPU to others
sudo nice -n -5 ./sensor.sh  # root only: boost priority
renice -n 15 -p 1234         # change priority of a running PID
ps -o pid,ni,cmd -p 1234     # NI column shows the nice value

In top, the NI column displays the value and PR shows the kernel's computed priority. The exam trap: renice on modern util-linux takes the priority directly (renice -n 5 -p PID), and a regular user who raised a job's nice value cannot lower it back below 0 without root.

Process States, Trees, and Extra Tools

The STAT column in ps aux compresses a process's state: R running or runnable, S interruptible sleep (waiting on I/O — most processes sit here), D uninterruptible sleep (usually disk or NFS; cannot be killed while it lasts), T stopped by job control or a debugger, and Z zombie — a dead process whose exit status its parent has not yet collected. Zombies hold no memory; a lingering zombie means a buggy parent, and killing the zombie's own PID does nothing — you signal (or kill) the parent so PID 1 can reap it. A child whose parent dies first is an orphan, immediately adopted and reaped by init/systemd.

To see parent-child relationships at a glance, use pstree -p or ps aux --forest, which indent children under their parents. For scripting, top -b -n 1 runs top once in batch mode so its output can be redirected to a file or piped to grep, and watch -n 2 'ps aux | grep nmap' re-runs any command on an interval.

Two more signals complete the job-control picture: SIGSTOP (19) suspends a process and, like SIGKILL, cannot be caught or ignored; SIGCONT (18) resumes a stopped process — kill -CONT is exactly what bg and fg send under the hood. Ctrl-Z actually sends SIGTSTP (20), the catchable, terminal-generated cousin of SIGSTOP, which is why interactive programs can react to being suspended.