Lesson 20 — Linux Service & Logs Troubleshooting Lab
ps + top + systemctl + journalctl
This lab combines core Linux service and logging tools into one practical troubleshooting sequence. The goal is to think like a real support technician when a user says, “The service is down and the server feels slow.”
Good troubleshooting moves in order: check whether the process exists → check live system pressure → check service status → read the logs for the real cause.
Determine whether a problem is caused by a missing process, a resource spike, a failed service state, or log-revealed configuration/runtime errors.
Lab Scenario
Ticket
A user reports:
Your job is to determine whether the issue is:
- The service process is not running
- The system is under CPU or memory pressure
- The service is in a failed or inactive state
- The logs show a configuration or runtime error
- The problem is broader than the service itself
1) Check Whether the Process Exists
Inspect running processes
Start by verifying whether the expected process exists at all.
What you are deciding
- Is the process running?
- Is it running under the expected user?
- Are there repeated or strange process entries?
Example problem
If only the grep result appears, the service process may not actually be running.
Do not assume the service is active just because the package is installed. Verify the process really exists.
2) Check Live System Pressure
Even if the process exists, a heavily loaded system may still feel “down” to users.
Inspect live usage
This helps you see whether CPU or memory pressure is affecting the host right now.
What to look for
- One process consuming very high CPU
- Memory pressure or heavy swap use
- A system that looks overloaded rather than simply “down”
Example problem
In this example, the real slowdown may be caused by another process rather than the web service itself.
3) Check Service Status
Now confirm what the service manager says.
Inspect service state
This shows whether the service is active, inactive, failed, or restarting.
What you are deciding
- Is the service active?
- Is it failed?
- Did it recently restart or crash?
Example problem
That tells you the service manager knows the service failed, but it does not fully explain why. That is where logs matter.
“Restarted the service” is not a full diagnosis. You still need to understand why it failed and whether the restart actually solved the cause.
4) Read the Logs for the Actual Cause
Logs often contain the best answer in the whole investigation.
Read recent service logs
This shows recent journal entries for that specific service.
Follow logs live
This is useful when you are restarting the service or reproducing the issue while watching logs update in real time.
Example problem
In that case, the service is not “randomly broken.” The logs point directly to a configuration error.
5) Fast Troubleshooting Pattern
- Check whether the process exists
- Check whether the system is under heavy load
- Check service state with
systemctl - Read recent service logs
- Write down the real failure point before changing anything major
Practical — Solve the Ticket
This practical is meant to feel like a real support task, not a trivia exercise.
Practical Task
- Check for the service process with
ps - Inspect live CPU and memory pressure with
top - Inspect the service state with
systemctl status - Read recent logs with
journalctl - Write one sentence describing the root cause and where the failure lives
Walkthrough
If the process is missing and the service is failed, the logs usually become the most important source of truth. If the service is active but the host is overloaded, the real issue may be system pressure rather than the service manager itself.
Example Ticket Note
Verified service process state, reviewed live system resource usage, checked service status with systemctl, and read recent journal entries. Determined the service failure was linked to a specific logged error rather than a general network outage.
Write Your Observation
Use a simple note like a junior admin or help desk tech would write.
Mini Knowledge Check
Score 75% or higher to unlock the next lesson link. Your score is saved on this browser.
1) Which command is strongest for checking whether a process exists?
2) Which command is best for checking live CPU and memory pressure?
3) Which command best checks whether a service is active, inactive, or failed?
4) What is the strongest troubleshooting habit in this lab?
Next Lesson
Tip: update the next lesson link when your page exists.