Diagnose and Recover Linux Processes

Investigate, control, and safely recover Linux processes by PID.

Introduction

30 Second Summary

When a computer suddenly slows down, restarting can feel like the quickest escape. That shortcut hides which program caused the trouble.

In this project, you will complete a controlled diagnosis of a CPU-intensive process on Linux Mint. Evidence from ps, top, and the /proc filesystem will guide a recovery aimed at one process ID.

What You'll Build

Your final demo shows the exact CPU-hungry process disappear after you prove which PID owns the problem.

By the end of this project, you'll have:

A repeatable incident you can launch under your normal user account.
A cross-checked diagnosis linking focused ps output with live top activity plus kernel data in /proc.
A safe recovery workflow that moves the exact target from running to stopped to resumed to fully removed.
Secret Mission: An optional two-process incident where you distinguish a CPU hog from a stopped sleeper before recovering each one correctly.

Are there any prerequisites?

You need a Linux Mint computer with Terminal access. You also need permission to use sudo only if the standard procps package needs to be restored.

Before We Start

This checkpoint sets the safety boundary for your Linux Mint Terminal lab. Sudo stays reserved for toolkit recovery while exact PID targeting protects unrelated processes.

Verify Your Process Toolkit

Finding a misbehaving process starts with trustworthy evidence. On Linux, that evidence comes from process commands plus the kernel's process records.

Your later recovery checks depend on the procps toolkit. They also depend on readable process data from the kernel.

In this step, you will identify the running kernel. You will verify the commands used throughout the lab.

You will also confirm that /proc exposes process status. A short top session proves the live view works.

In this step, get ready to:

Confirm that your computer is running a Linux kernel.
Verify the process inspection commands.
Confirm the kernel-backed process views.

Confirm the Linux kernel

The kernel manages every process you investigate. Confirming the operating environment gives the rest of the lab a reliable foundation.

Start a Linux Mint Terminal session from your desktop's application launcher.
Confirm that the shell is running under your normal user account.
Identify the running kernel by running this command:

uname -a

What does this command show?

The uname -a command prints information about the running kernel. This confirms that your process tools are operating on Linux.

You'll see output that identifies a Linux kernel. The line also includes details from your local system.

Kernel output look unexpected?

Confirm that you started Terminal on the Linux Mint computer assigned to this project. Stop here if the output identifies another operating system.

Ask for help with the environment before continuing: Help me understand my kernel output.

Verify the process commands

The process workflow uses one command for snapshots. It uses another command for live monitoring.

You also need a working signal command. These checks confirm that each part is available before you create an incident.

Check the process command versions plus the supported signal list by running these commands:

ps -V
top -V
kill -l

What do these checks prove?

The ps -V command prints the installed procps version for ps.
The top -V command displays version information for top.
The kill -l command lists the signal names supported by your system.

✔️ All three checks work

Your terminal shows version information for ps plus top. It also shows a list of signal names from kill -l.

The shell also provides wait for known child processes. Your process-control commands are ready.

ⓧ ps or top is missing

This is the only part of the lab that may require elevated privileges. The package commands restore the toolkit used by your normal account.

Refresh the available package information by running this command:

sudo apt-get update

What does this command do?

The command refreshes the package metadata used by Linux Mint. It prepares the package manager to install the current repository version of procps.

The update finishes when your shell prompt returns.

The installation may pause for your sudo password. It may also ask you to approve the package change.

Install the procps package by running this command:
Respond to any password or confirmation prompt so the installation can finish.

sudo apt-get install procps

What does procps provide?

The procps package supplies process utilities such as ps plus top. Installing the package restores the missing monitoring commands.

The installation is complete when the command returns to your shell prompt.

Repeat the process command checks by running these commands:

ps -V
top -V
kill -l

What confirms the repair?

The first two commands now print version information. The final command prints the supported signal names.

You now have the process snapshot tool plus the live monitor required for the incident.

Commands still unavailable?

Make sure both package commands completed without a repository or network failure. Start a fresh Terminal session if the installation succeeded but the shell still cannot find a command.

Get help with the failed check: Help me restore the procps commands.

Elevated access ends with the package fallback. Every process created later runs under your normal user account.

Inspect procfs and open top

The procfs view exposes process information supplied by the kernel. The /proc/self/status file provides a readable status report for the process accessing it.

Read the current process status by running this command:

cat /proc/self/status

What does this status file contain?

The self directory points to the process reading the file. The status file presents kernel process details in a human-readable form.

Its fields cover identity, state, memory use, parentage, plus thread count. This is the kernel-backed record that later checks compare with process tools.

This status output is dense, so finding the important lines can feel fiddly. Focus on the six fields used throughout the investigation.

Locate the Name field.
Locate the State field.
Locate the Pid field.
Locate the PPid field.
Locate the VmRSS field.
Locate the Threads field.

You'll see each field on its own line with a value from the kernel's process record.

A status file gives you one process record. Live monitoring adds a changing task table for the whole system.

Before you run the monitor, make a quick prediction about whether the task table stays fixed or keeps changing.

Open the live task monitor by running this command:

top

What does top show?

The top command provides a dynamic view of Linux processes. It updates the task information while the monitor remains open.

Pressing q exits the monitor. That returns control to your shell.

You'll see a dynamic task list with process rows that update on screen.

Press q to exit top.

You'll return to your normal shell prompt. That's the toolkit confirmed from kernel identity through live process monitoring.

Still unable to open top?

Return to the missing-tool tab if the monitor does not start. Confirm that the procps installation completed before repeating the version check.

Ask for targeted help if the problem continues: Help me open top on Linux Mint.

✔️ Awesome, I've got everything!

Your Linux Mint Terminal session has the process toolkit needed for the controlled incident.

ⓧ I'd like to double check the full code

Your Linux Mint Terminal session confirms a Linux kernel. The procps commands ps plus top are available.

The shell builtins kill plus wait are available. The /proc/self/status file provides readable process data.

You opened top to view its live task table. You exited it with q.

Your process toolkit is ready. Next, you will create one controlled CPU-intensive process and experience the blind spot in a default snapshot.

Create the Controlled Incident

Your Linux process toolkit is ready. You can now create a safe target under your normal account.

A process can consume a CPU core while looking ordinary in a basic process snapshot. This step lets you experience that troubleshooting blind spot with a process you own.

In this step, get ready to:

Launch one controlled CPU-intensive process under your normal account.
Capture its exact process ID in LAB_PID.
Inspect the limited default ps snapshot.

Start the controlled CPU loop

A background job can run while your Terminal remains available. This loop stays within your normal user account.

Create the CPU-intensive background job in the Linux Mint Terminal from earlier by running this command:

(while :; do :; done) &

How does the loop create load?

The : command returns a successful result.
The while loop repeats while that condition succeeds.
The trailing & runs the loop asynchronously.
The background process repeatedly uses CPU time until you stop it later.

The shell exposes the most recent background process ID through $!. Saving that value gives every later diagnostic command one precise target.

Store the loop's process ID in LAB_PID by running this assignment immediately:

LAB_PID=$!

What does this assignment store?

The $! parameter expands to the process ID of the most recent background job.
The LAB_PID variable keeps that exact identifier available in your current shell.
The saved PID lets you inspect one process without matching unrelated processes by name.

Lost the background PID?

Keep using the same Linux Mint Terminal session where you assigned LAB_PID.
Restart the controlled loop if the original background process ended.
Capture the new process ID immediately after restarting the loop.

Help me recover the correct lab PID.

Reveal the default snapshot blind spot

A default process snapshot can confirm whether a specific PID exists. You will now test whether that view explains the process's behaviour.

Before you run the check, do you think the default snapshot will reveal why the process is misbehaving?

Inspect only the PID stored in LAB_PID by running this command:

ps -p "$LAB_PID"

What does this command check?

The -p option limits the snapshot to the selected process ID.
The shell replaces $LAB_PID with the identifier you saved.
The resulting row proves that your controlled process is still running.

You should see one target row for the PID stored in LAB_PID. The displayed columns do not include %CPU or PPID.

You have now reproduced the exact blind spot that process triage must overcome.

No target row?

Confirm that you are still using the Terminal session where you created the process.
Check that LAB_PID was assigned immediately after the background loop started.
Restart the loop if the controlled process was ended accidentally.

Help me find my controlled process.

Keep this Linux Mint Terminal session open so LAB_PID remains available.

Your controlled CPU hog is running under your account. Next, you will expose its CPU demand and parent context with focused process views.

Identify the CPU Hog

You kept the controlled CPU loop alive under your normal account. Its process ID remains stored in LAB_PID, so every check stays focused on the process you created.

The default ps snapshot hid the resource pressure behind a limited set of columns. That blind spot makes it difficult to connect CPU usage to an exact process.

A focused snapshot exposes the details the default view hid. Live monitoring then shows how the CPU demand changes over time.

In this step, get ready to:

Identify the controlled process through a focused ps snapshot.
Interpret each custom field in the target row.
Watch its CPU activity change in a focused top view.

Inspect the focused snapshot

A custom output format turns ps into a targeted process report. Each field answers a specific triage question about the PID you already saved.

Generate the focused snapshot by running this command:

ps -p "$LAB_PID" -o pid,ppid,state,pcpu,comm

What Do These Fields Reveal?

The pid field identifies the exact target process.
The ppid field identifies the target's parent process.
The state field reports the process state as one character.
The pcpu field reports CPU time as a percentage of the process's elapsed lifetime.
The comm field displays the command name.

Match the value under PID to the number stored in LAB_PID.
Read the remaining custom columns from left to right.
Confirm that the value under %CPU is elevated.

That closes the first blind spot. Your focused snapshot now ties the CPU pressure to one exact PID.

Target Row Missing?

Return to the same Terminal session that contains LAB_PID.
Check that LAB_PID appears exactly as shown in the command.
Keep the quotation marks around "$LAB_PID".

Help me find my missing process row.

Watch CPU activity live

The ps percentage summarizes CPU use across the process's lifetime. The top percentage measures activity since its previous screen update.

Before you run this, predict whether the CPU value stays flat or changes across several refreshes.

Focus the live monitor on your saved PID by running this command:

top -p "$LAB_PID"

What Does This Command Do?

The -p "$LAB_PID" option limits the task table to your controlled process.
The live task table refreshes repeatedly to reveal changes in CPU activity.
The interactive view remains active until you press q.

Watch the target through several screen updates.
Compare the changing %CPU value with the earlier ps percentage.
Press q to exit the live view.

You'll see the same PID with elevated CPU activity that changes between refreshes.

After q, you'll return to your shell prompt. The controlled process remains available for the next investigation.

Process Missing from top?

Confirm that you are using the Terminal session that still holds LAB_PID.
Watch several refreshes if the CPU percentage briefly dips.
Press q if you need to return safely to the shell prompt.

Help me troubleshoot the focused live view.

You have identified the CPU hog through both a focused snapshot and a live monitor. Next, you'll trace that exact PID back to the kernel-provided process record.

Inspect the Kernel Process Record

Your focused ps snapshot and live top view have exposed the controlled loop's identity. They have also shown its CPU demand.

Now you need to prove where those details come from. Linux procfs exposes a kernel-provided record for each running PID under /proc.

In this step, get ready to:

Inspect the kernel status record for the controlled process.
Reconcile its identity and state with the focused process snapshot.

Connect the PID to procfs

Every running process has a directory named after its PID inside /proc. Its status file presents kernel process details in a readable format.

Switch back to the Linux Mint Terminal from earlier.
Display the controlled process's status record by running this command:

cat "/proc/$LAB_PID/status"

What does this status file show?

The Name field reports the process name.
The State field shows the current state code plus its label.
The Pid field identifies this process.
The PPid field identifies the parent process.
The VmRSS field shows the process's resident memory.
The Threads field reports the process's thread count.

Locate the Name, State, Pid, PPid, VmRSS, and Threads fields in the output.
Compare the Pid value with the PID from your focused ps snapshot.

You should see all six fields in the status record. The Pid value matches the controlled process stored in LAB_PID.

Status File Missing?

Repeat the focused process snapshot from earlier to confirm that LAB_PID still has a process row.
Keep using the same Terminal session because shell variables belong to that session.
Check that the path contains $LAB_PID with the dollar sign.

Help me inspect the procfs status file.

Reconcile the kernel and snapshot views

The status record provides the kernel-facing view of the process. Shared identity and state fields let you connect that record to the summary produced by ps.

Before you rerun the snapshot, do you expect its PID, PPID, and state to agree with the status record?

Recreate the focused process summary by running this command:

ps -p "$LAB_PID" -o pid,ppid,state,pcpu,comm

How Do the Views Connect?

The pid column corresponds to the status record's Pid field.
The ppid column corresponds to the status record's PPid field.
The state column corresponds to the one-character code at the start of the State field.
The comm column can be checked against the process name shown by Name.
The pcpu column adds a CPU-use summary to the focused snapshot.

Match the PID column with the status record's Pid value.
Match the PPID column with the status record's PPid value.
Compare the one-character STATE value with the code in the status record's State field.

You should see the same PID and parent PID in both views. The process state should also agree between the focused snapshot and the kernel record.

Fields Do Not Match?

Confirm that both commands use the same LAB_PID variable.
Compare the one-character state code from ps with the first code in the longer procfs state value.
Rerun both views close together because a live process can change state between observations.

Help me reconcile the process fields.

That is a solid operator checkpoint. You have linked the process summary back to its kernel-provided record.

The controlled process is still running under its exact PID. Next, you'll control that PID with targeted signals and verify each state transition.

Stop, Resume, and Terminate Safely

Your focused ps view now matches the kernel record in procfs. You know the exact process ID that is consuming CPU.

Diagnosis is incomplete until you can control the exact target by PID. This step proves each transition through process signals before removing the process cleanly.

In this step, get ready to:

Stop the controlled loop in a verifiable state T.
Resume the exact PID before terminating it with TERM.
Prove complete cleanup after reaping the terminated background job.

Prove the stopped state

A stopped process remains present while its execution is paused. Checking the PID after the signal proves that you controlled the intended loop.

Stop the controlled loop by sending STOP to the PID stored in LAB_PID with this command:

kill -s STOP "$LAB_PID"

What Does STOP Do?

STOP pauses execution of the process at the specified PID.
The shell expands "$LAB_PID" to the PID you recorded earlier.
Targeting that saved PID protects unrelated processes from the signal.

Predict which state code the focused snapshot shows for the stopped process.
Inspect the stopped state by running this command:

ps -p "$LAB_PID" -o pid,state,pcpu,comm

What Should I See?

The state column should show T for the target row.
The %CPU value can still include CPU time accumulated before the stop.
The loop no longer consumes active CPU while its state remains T.

Not Seeing State T?

Confirm that the displayed PID matches the value stored in LAB_PID.
Check that the signal name is written as uppercase STOP.

If the row is absent, the controlled loop may already have ended.

Help me diagnose why the process did not enter state T.

Control the loop's final transitions

CONT allows a stopped process to run again. TERM requests normal termination from the same exact PID.

Resume the stopped loop by sending CONT with this command:

kill -s CONT "$LAB_PID"

What Does CONT Do?

CONT allows the stopped process to continue executing.
The loop can consume CPU again after the signal takes effect.
The saved PID keeps this transition confined to the controlled process.

Predict whether the state column still shows T after CONT.
Inspect the resumed process by running this command:

ps -p "$LAB_PID" -o pid,state,pcpu,comm

What Should Change?

The state should no longer remain T.
The exact state can change as the scheduler runs the loop.
CPU activity can increase because the loop is executing again.

Terminating a process can feel risky. Your saved PID keeps the next signal aimed at the controlled loop.

Terminate the controlled loop by sending TERM with this command:

kill -s TERM "$LAB_PID"

What Does TERM Do?

TERM requests termination of the process at the specified PID.
The controlled shell loop uses the signal's default termination action.
LAB_PID still records the former target PID after the process terminates.

Signal Not Reaching the Process?

Confirm that LAB_PID still contains the controlled process's PID.
Check that the signal name is written as uppercase TERM.

A message about a missing process means the loop ended before the signal reached it.

Help me safely troubleshoot the TERM signal.

Confirm complete cleanup

A terminated child can still have saved status in the current shell. wait consumes that status for the known child process.

Reap the terminated background job by running this command:

wait "$LAB_PID"

What Does wait Do?

wait waits for the known child identified by LAB_PID to finish.
It removes the successfully waited-for PID from the shell's known process list.
A quiet return to the prompt is a valid result.

Predict whether any process row remains for LAB_PID after termination plus waiting.
Verify complete removal by running this command:

ps -p "$LAB_PID"

What Should I See?

You should see the column headings without a process row for LAB_PID. That absence proves the controlled loop is no longer running at the recorded PID.

Still Seeing a Process Row?

Compare the remaining row's PID with the value stored in LAB_PID.
Avoid sending another signal until the PID match is certain.

Help me verify whether the controlled process was fully removed.

That is a clean recovery. The CPU-intensive loop is gone without disturbing any unrelated process.

Secret mission

Triage a Two-Process Incident

Create two controlled symptoms under your account. Diagnose which PID is consuming CPU. Recover each process with a signal chosen from its observed state.

Clean Up Your Resources

You handled cleanup during the recovery workflow. This local Linux lab has no ongoing costs.

Resources you used:

Current Linux Mint Terminal session with three former process IDs recorded as shell variables (no cost).
Controlled loop formerly tracked by LAB_PID. It has been terminated. Its background job has been reaped.
Bonus loop formerly tracked by HOG_PID. It has been terminated. Its background job has been reaped.
Bonus sleeper formerly tracked by SLEEP_PID. It has been terminated. Its background job has been reaped.

Keep everything running

No action is needed. Choose this if you want the current Terminal history available while you review the workflow.

Keep the Linux Mint Terminal session open while you review its command history.
Use the recorded PID variables only to revisit the completed checks.

Pause - I'll come back to this later

No controlled processes remain to pause. The lab is already at a safe stopping point.

Leave the system as it is until you return.

Delete - I don't want to use this again

Remove the last temporary session state. The controlled processes are already gone.

Confirm that all controlled PIDs remain absent by running these commands:

ps -p "$LAB_PID"
ps -p "$HOG_PID,$SLEEP_PID" -o pid,ppid,state,pcpu,comm

What should you see?

Both checks should return no process rows. This confirms that the exact controlled PIDs remain absent.

See an unexpected process row?

Do not send another signal if a row appears. The original lab jobs were already reaped.

Help me inspect an unexpected process row safely.

Close the Linux Mint Terminal window to discard the recorded PID variables from the current shell session.

Nice Work!

You did it! You completed a targeted process recovery on Linux without disturbing unrelated processes.

You've learned how to:

Exposed the blind spot in default ps output. Used a focused snapshot plus live top monitoring to identify the CPU-intensive process.
Correlated focused output with procfs evidence from /proc/$LAB_PID/status.
Used targeted signals to stop the exact PID. Resumed the same process before terminating it. Reaped its background job with wait. Confirmed that no process row remained.
Secret Mission: Distinguished a CPU hog from a stopped sleeper through observed state and CPU data. Recovered both exact PIDs with deliberate cleanup.

Ready to quiz yourself?