5.2 Managing Processes

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

5.2 Managing Processes

Key Takeaways Explain This Topic AI

ps aux (BSD style) shows every process with %CPU and %MEM; ps -ef (System V style) shows the full command line with PPID — both answer "what is running".

kill sends signals, not just death: SIGTERM (15) asks politely, SIGKILL (9) cannot be caught or ignored, SIGHUP (1) tells daemons to reload config.

Job control: append & to background at launch, Ctrl-Z suspends, bg resumes in the background, fg brings a job to the foreground, jobs lists them.

nohup makes a command immune to SIGHUP so it survives terminal logout; disown removes a job from the shell's table entirely.

nice values run from -20 (highest priority, root only) to +19 (lowest); launch with nice -n 10 and adjust later with renice.

Last updated: July 2026

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:

• Signal Number Behavior
• SIGHUP 1 Hang up — daemons conventionally reload their config; shells forward it to jobs on logout
• SIGKILL 9 Force-kill; cannot be caught, blocked, or ignored; may leave temp files behind

SIGTERM 15 Polite termination request (the default); the process can trap it and clean up 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.