Lesson 22 • Linux Review

Lesson 22 • Linux Review

Linux Help Desk Review Lab

This lesson is about fast recognition and disciplined troubleshooting. You will work through short Linux support tickets, choose the best first command, identify the likely cause, apply the safest fix, and document the result.

service checks logs network basics permissions ticket notes
Difficulty Review / applied beginner
Estimated Time 15–25 minutes
Main Skill Choosing the right first step

What this review is building

  • Confidence with common Linux support tickets
  • Better command selection under pressure
  • Cleaner separation of symptom vs. cause
  • Safer troubleshooting habits
  • Short, professional ticket documentation

Help desk mindset

Good technicians do not start with random fixes. They ask: What is the first command that gives me real evidence?

That habit saves time, reduces mistakes, and makes your notes more credible.

Shift Queue

You are covering the Linux support queue. Five short tickets are waiting.

Ticket 1: Web service is down after changes
Ticket 2: Server cannot reach outside networks
Ticket 3: Script fails with Permission denied
Ticket 4: User says disk is full
Ticket 5: Hostname does not resolve from the system
Ticket 1 • Services

Web Service Down

User report: “The internal site stopped loading after some service changes.”

Best first command

Start with service state before guessing.

systemctl status nginx

Likely clue

Service status shows failure, but not always root cause.

Active: failed (Result: exit-code)

Best next command

Now read the logs tied to that service.

journalctl -u nginx -n 20

Safe fix pattern

Find the real conflict, correct it, then verify.

Check the exact error, resolve the conflict or bad config, restart the service, and confirm it is active.

Ticket 2 • Networking

No Outside Connectivity

User report: “The server is on, but it can’t reach the internet or other outside networks.”

Best first command

Confirm the adapter and IP assignment first.

ip addr

Likely next check

If an IP exists, routing is the next suspect.

ip route

Common root cause

Internal address exists, but traffic has no default path.

Missing or incorrect default gateway route.

Safe fix pattern

Restore the correct route, then verify by testing gateway and external reachability.

ping -c 2 192.168.1.1 ping -c 2 8.8.8.8
Ticket 3 • Permissions

Script Will Not Run

User report: “The backup script is there, but it says Permission denied.”

Best first command

Inspect file permissions before changing anything.

ls -l backup.sh

Likely clue

The file is present, but not executable.

-rw-r–r– 1 student student 842 Mar 20 09:12 backup.sh

Likely cause

No execute bit is set.

The script is readable but not executable.

Safe fix

Add only the needed permission, then test.

chmod +x backup.sh ./backup.sh
Ticket 4 • Storage

Disk Full Complaint

User report: “The server says there’s no space left.”

Best first command

Check filesystem usage first.

df -h

Likely next command

If one filesystem is near 100%, find what is consuming space.

du -sh /var/*

Common cause

Logs, caches, or large files filled a partition.

One directory or log location grew until the filesystem filled up.

Safe fix pattern

Identify the source, clean up carefully, and verify free space after.

Do not blindly delete files. Confirm what is safe to remove, then recheck with df -h.

Ticket 5 • Name Resolution

Hostname Does Not Resolve

User report: “I can ping an IP, but the hostname does not work.”

Best first command

Prove the difference between IP reachability and name resolution.

ping -c 2 8.8.8.8 ping -c 2 example.com

Likely next check

If IP works but hostname fails, inspect DNS settings.

cat /etc/resolv.conf

Common cause

Name resolution is broken even though network path exists.

Missing, incorrect, or unreachable DNS server configuration.

Safe fix pattern

Correct DNS settings and re-test by hostname.

Validate network first, then correct the resolver configuration and verify hostname resolution works again.

Fast Command Map

Problem Type Best first command Why it is the right first move
Service will not start systemctl status service-name Shows current service condition before deeper log review.
Need service root cause journalctl -u service-name Logs usually explain the actual failure.
No connectivity ip addr Confirms whether the adapter is up and has an address.
Outside traffic fails ip route Reveals missing or incorrect default routes.
Permission denied ls -l Quickly exposes missing execute bits or wrong ownership.
Disk full df -h Shows which filesystem is actually out of space.
Hostname fails cat /etc/resolv.conf Helps verify DNS resolver configuration.

Ticket Note Practice

Write a short shift summary covering at least three of the tickets above.

Gold-standard note:

Reviewed multiple Linux help desk tickets. For the web outage, checked service state with systemctl status and used journalctl to continue root-cause analysis. For the network issue, confirmed interface addressing with ip addr and checked routing with ip route. For the script execution issue, verified permissions with ls -l, corrected execute access, and re-tested. Also reviewed disk usage with df -h for storage concerns and verified DNS-related troubleshooting by separating IP connectivity from hostname resolution.

Micro-Quiz

Score at least 75% to unlock the next lesson.

1) A Linux service is down. What is the best first command?

2) Which command best helps explain why a service failed?

3) A server has an IP address but cannot reach outside networks. What command is most useful next?

4) Which command is the best first check when a user says a disk is full?

5) What is the strongest support habit this lesson reinforces?

Lesson complete saved. Good work.
You need 75% or higher to unlock the next lesson.

Next Lesson

Unlock the next lesson by passing the quiz or marking this lesson complete.

Next: Linux CLI Mini Capstone

Leave a Comment