Lesson 11 — Processes & Services Basics
ps + top + systemctl + journalctl
When a Linux system feels slow or a service is not working, the right move is not random guessing. This lesson teaches a clean troubleshooting flow using four high-value tools: ps to inspect processes, top to watch live resource usage, systemctl to check and manage services, and journalctl to read logs and find out what actually failed.
Good troubleshooting moves in layers: what is running → what is consuming resources → is the service active → what do the logs say.
Check running processes, spot heavy CPU or memory use, verify whether a service is active, restart a service safely, and inspect logs for recent service failures.
Lesson Objectives
By the end of this lesson
- Inspect running processes with
ps - Watch live CPU and memory usage with
top - Check and restart services with
systemctl - Read recent logs with
journalctl - Follow a clean service troubleshooting sequence
Why this matters
- A slow system may be caused by one heavy process, not the whole OS
- A service can be installed but inactive or failed
- Logs often show the real reason a service will not start
1) Check Running Processes with ps
Show many running processes
Use ps aux to view active processes and basic details like user, CPU, memory, and command.
Search for a specific process
Combine ps with grep when you want to check whether a specific program appears to be running.
What to look for
- Which user started the process
- Whether the process appears multiple times
- Whether CPU or memory usage looks unusually high
- Whether the command matches the service you expect
Do not assume a service is running just because the software is installed. Verify the process actually exists.
2) Watch Live Resource Usage with top
top shows live activity and helps you spot processes using heavy CPU or memory right now.
Open live view
This gives a moving view of the system. It is useful when a machine feels slow or unstable.
What top helps you answer
- Is one process spiking CPU?
- Is memory under pressure?
- Does the system look busy or mostly idle?
- Which process should you inspect next?
Example interpretation
In this example, python3 is consuming far more CPU than the web server. That points you toward the likely cause of slowdown.
3) Check Services with systemctl
systemctl is used on many modern Linux systems to inspect and manage services.
Check service status
This helps you see whether a service is active, inactive, or failed.
Restart a service
Restarting can help after a configuration change or a stuck state, but do not treat restart as your first and only idea.
Enable a service at boot
This makes the service start automatically when the system boots, if that behavior is desired.
“Service restarted” is not a full diagnosis. Good technicians ask why the service was down and confirm whether it stays healthy after restart.
4) Read Logs with journalctl
journalctl lets you inspect systemd journal logs. When a service fails, this is often where the real answer lives.
Show recent logs for a service
This shows recent entries for one specific service.
Follow logs live
This is useful when testing a restart or trying an action while watching the logs update in real time.
Why logs matter
If a service fails to start, the status output may tell you that it failed, but the logs are often what tell you why.
5) Fast Troubleshooting Pattern
- Check whether the process exists
- Check whether the system is under heavy load
- Check whether the service is active or failed
- Read recent logs for the service
- Restart only after you understand the problem enough to act safely
Practical — Check a Failed or Slow Service
This practical teaches a clean admin workflow instead of random command memorization.
Practical Task
- Check whether a target process exists with
ps - Look for unusual CPU or memory use with
top - Check service state with
systemctl status - Read recent logs with
journalctl - Write one sentence describing what looks healthy and what does not
Walkthrough
You may not have every service installed, and that is fine. The point is to follow a logical sequence: check for the process, inspect the system state, verify service status, and then read logs before taking action.
Example Ticket Note
User reported web service unavailable. Verified service status with systemctl, confirmed process state with ps, reviewed recent journal entries with journalctl, and identified recent service failure for further correction.
Write Your Observation
Use a simple note like a junior admin 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 best for viewing many running processes?
2) What is a strong use for top?
3) Which command checks whether a service is active or failed?
4) Why might you use journalctl after checking a failed service?
Next Lesson
Tip: update the next lesson link when your page exists.