Version 1 · Chapter 12Reading mode

Trace a process before stopping it

By the end: Inspect process identity and relationships, then stop only a process you started.

The idea

A PID identifies a process at a moment in time and can later be reused. A program name may match many processes. A signal is a request or notification; kill does not always mean immediate termination. Inspect the exact PID and prefer a graceful termination before considering a forced stop.

Your command toolkit

ps

What it solves: Take a snapshot of running processes.

bash

ps -p "$$" -o pid,ppid,comm

### top / htop **What it solves:** Observe changing CPU and memory use. ```bash top ``` Press q to exit. htop is an optional interactive alternative. Both offer actions that change processes, so begin with observation. ### pstree **What it solves:** See parent-child relationships. ```bash pstree -p "$$" ``` Shows the shell's process subtree with PIDs. A parent-child relationship helps explain which service or shell started work. ### pidof **What it solves:** Find PIDs by executable name. ```bash pidof bash ``` There may be several matches or none. Inspect each match before targeting it with a signal. ### kill **What it solves:** Send a signal to a specific process. ```bash kill -l ``` Lists signal names. SIGTERM is the usual default termination request; SIGKILL prevents cleanup. The lab below targets only its own sleep process. ### killall **What it solves:** Understand signalling every process with a name. ```bash killall --help ``` On Linux this can signal all matching names. That scope is much wider than one verified PID; avoid it on shared workloads without a precise plan. ### nice / renice **What it solves:** Understand CPU scheduling priority. ```bash nice -n 10 sleep 1 renice --help ``` A higher niceness value normally means lower scheduling priority. renice changes existing processes; raising priority often needs privileges. ### ionice **What it solves:** Inspect an I/O scheduling priority. ```bash ionice -p "$$" ``` Queries your shell's I/O priority. Its practical effect depends on the active I/O scheduler and storage stack. ## Before you move on Try the guided lab below. Compare the result with the explanation, then record your reasoning in the workbook. A missing optional program or a restricted environment is something to explain, not a reason to change system settings blindly.

Practice with evidence

Predict the result
Run the guided lab
Compare the output
Explain your choice

A worked example

Guided lab

bash

sleep 60 &
si_job=$!
ps -p "$si_job" -o pid,ppid,comm
kill -TERM "$si_job"
wait "$si_job"
printf 'Child exit status: %s\n' "$?"

What to expect: You inspect and terminate your own sleep child. Bash normally reports status 143 for SIGTERM; it is expected here.

Make it yours: Explain why you captured $! immediately, how you checked the process, and why a name-based signal would have been broader.

Read further

Debian reference: Linux fundamentals ↗www.debian.org

Apply what you learned

Your private practice

Explain why you captured $! immediately, how you checked the process, and why a name-based signal would have been broader.

What should you normally try before SIGKILL when stopping a verified process?Signal every process with its nameA graceful termination such as SIGTERMDelete its executable

Answers are private. Completion requires the correct knowledge-check answer and a written response when an activity is included.

Restore a downloaded workbook

Choose a recovery file for this course and version. Review the recovered copy before saving it to your account.

Workbook recovery file

Ask a question or report a problem

Describe what needs attention. Your private answer is shared only if you select the option below.