Linux Troubleshooting Capstone Lab
This capstone pulls together the skills you have been building: checking service status, reading logs, confirming network settings, validating permissions, and documenting your work like a real support tech.
What this lab is training
- Do not guess. Check the system first.
- Use command output to narrow the problem.
- Separate symptoms from root cause.
- Make a clean fix, then verify the result.
- Write a short ticket update that proves what you did.
Capstone mindset
A weak troubleshooter jumps to random fixes. A strong troubleshooter follows a sequence: observe → check status → read logs / test → identify cause → fix → verify → document.
That sequence is what employers trust.
Simulated Ticket Queue
You are the support tech on shift. Three Linux issues have come in.
User says the internal test site stopped loading after a reboot.
User says the server is up, but cannot reach the gateway or external hosts.
User says the backup script exists, but will not run.
Website Down — Service Fails to Start
User report: “The internal web page won’t load after the reboot.”
Break
The service does not start successfully.
Diagnose
Read status first, then read the service logs.
This tells you the web service is failing because another process is already using port 80.
Fix
Find the conflict, stop it, and verify nginx starts.
Root cause: another service was already bound to port 80.
No Network — Adapter / IP / Gateway
User report: “The server is on, but it can’t reach anything.”
Break
The machine has no usable network route.
Diagnose
The interface has an IP, so now check the route and gateway path.
There is no default gateway route listed, so traffic to outside networks has nowhere to go.
Fix
Add or restore the correct default route, then test again.
Root cause: missing default gateway route.
Backup Script Won’t Run — Permission Denied
User report: “The backup script is there, but it won’t execute.”
Break
The file exists, but execution fails immediately.
Diagnose
Check the permission bits before changing anything.
The file is readable, but not executable. There is no x bit in the permission string.
Fix
Add execute permission, then run the script again.
Root cause: the script did not have execute permission.
Command-to-Problem Map
| Command | What it helps you check | Why it matters |
|---|---|---|
systemctl status <service> |
Current service state | Shows whether the service is running, failed, or disabled. |
journalctl -u <service> |
Service-specific logs | Logs usually expose the actual cause, not just the symptom. |
ip addr |
Interface state and IP address | Confirms whether the adapter is up and whether it has an address. |
ip route |
Routing table | Tells you whether the system knows where to send traffic off-network. |
ls -l |
Permissions and ownership | Fast way to spot missing execute bits or wrong ownership. |
Ticket Note Practice
Write a short support note as if you completed all three issues during a shift handoff.
Gold-standard note:
Investigated three Linux support issues. For the web service outage, used systemctl status nginx and journalctl -u nginx to identify a port 80 conflict with another service; stopped the conflicting service and verified nginx started successfully. For the network issue, confirmed interface IP with ip addr and identified a missing default route using ip route; restored the gateway route and verified connectivity with ping. For the backup script failure, used ls -l to confirm missing execute permissions, applied chmod +x, and verified successful execution.
Micro-Quiz
Score at least 75% to unlock the next lesson.