Linux CLI Mini Capstone
This mini capstone combines the core Linux command-line habits you have been building. You will inspect a broken support situation, navigate the filesystem, verify permissions, review logs, test connectivity, and document the result like a real junior technician.
What this lesson trains
- Moving through the filesystem with purpose
- Using command output to narrow the problem
- Recognizing permission and service issues quickly
- Separating network failure from DNS failure
- Writing a short, professional support note
Capstone mindset
The goal is not to memorize random commands. The goal is to think in sequence: find the file → inspect the state → confirm the cause → fix safely → verify → document.
Mini Capstone Ticket
User report: “The backup task didn’t run, the status page is stale, and I’m not sure whether the service or script is broken.”
You are asked to check the Linux system and leave a clean update for the next tech.
Find the Script and Check the Working Area
The suspected backup script is somewhere under /opt/backup. Start by locating yourself and inspecting files before changing anything.
Best starting commands
Confirm where you are and list what exists.
What you notice
The script exists, but you still do not know whether it can run.
Likely issue
The script is present, but one important permission is missing.
No execute bit is set on run-backup.sh.
Safe fix
Add only what is needed, then test again.
Run the Script and Inspect the Log
Now that the script can execute, you run it and check whether the task actually succeeded.
Run the task
Test the script directly and look for an error.
Observed result
The script runs, but reports it cannot reach the remote target.
Check the local log
Read the latest recorded entries instead of guessing.
What the log confirms
The backup job is failing at network reachability, not file execution.
Test Connectivity Before Blaming the Service
Since the log points to reachability, the next move is to prove whether this is a general network issue or only a hostname issue.
First tests
Test IP reachability and hostname resolution separately.
Observed clue
The IP responds, but the hostname does not.
Likely cause
This is not a full network outage.
Likely DNS or hostname resolution issue.
Best next check
Inspect resolver configuration instead of restarting random services.
Confirm the Status Page Service
The user also mentioned the local status page looks stale. Now verify whether the related service is active.
Best first command
Check the service state directly.
Possible clue
The service may be inactive, failed, or running with stale data.
Interpretation
If the page service is running, it is probably not the root cause.
The stale page is likely a symptom of the failed backup/update workflow, not a dead service.
Support takeaway
Do not restart a healthy service just because the page looks wrong.
Evidence says the main failure chain began with script permissions and then moved to hostname resolution.
Mini Capstone Command Map
| Task | Useful command | Why it matters |
|---|---|---|
| Confirm location | pwd |
Prevents mistakes by showing where you are in the filesystem. |
| List files and permissions | ls -l |
Shows whether a file exists and whether it is executable. |
| Read recent file-based logs | tail -n 20 logfile |
Quickly surfaces the latest relevant errors. |
| Check service health | systemctl status service-name |
Shows whether a service is actually running or failed. |
| Test reachability | ping |
Helps separate general connectivity issues from DNS/name issues. |
| Inspect resolver settings | cat /etc/resolv.conf |
Useful when hostname lookup fails but IP connectivity works. |
Ticket Note Practice
Write a short support note summarizing the capstone issue chain and what you verified.
Gold-standard note:
Investigated failed backup workflow from the Linux CLI. Verified script location under /opt/backup and used ls -l to identify missing execute permission on run-backup.sh. Applied execute permission and re-tested. Script then ran but failed on remote target reachability. Reviewed recent task log entries with tail, which confirmed the job was aborting before transfer. Tested network by separating IP connectivity from hostname resolution and identified a likely DNS / resolver issue rather than a full network outage. Checked the related status page service with systemctl status and confirmed it was running, indicating the stale page was likely downstream from the failed backup/update process.
Micro-Quiz
Score at least 75% to unlock the next lesson.