On this page
The core idea
Most Linux servers provide the same basic evidence: which processes are running and what resources they use, how full the disks are, what the service manager reports and what the logs say. On many distributions systemd manages services, systemctl reports their state and journalctl reads their logs. Tools such as top or htop show CPU and memory, df and du show disk use and ss shows listening ports. Looking at these in a consistent order turns a stressful incident into a checklist.
A practical approach
Step 1
Check the service state with systemctl status your-service, which shows whether it is running, recent log lines and the exit code if it failed.
Step 2
Read recent logs with journalctl -u your-service --since "30 minutes ago", or the application's own log files if it writes them elsewhere.
Step 3
Check resources: top or htop for CPU and memory, free -h for memory and df -h for disk space. A full disk causes many confusing failures.
Step 4
Confirm the service is listening where expected with ss -tlnp, and test it locally with curl before blaming the network or firewall.
Step 5
Write down what you found and what you changed, in order, so the incident can be reviewed and repeated fixes automated.
Worked example
An API stops responding and restarting it does not help. systemctl status shows it exits immediately with an error, and journalctl reveals 'No space left on device' when writing a temporary file. df -h confirms the disk is full, and du points to old log files that were never rotated. Clearing old logs and configuring log rotation restores the service and prevents a repeat.
A mistake to avoid
Do not make several changes at once while investigating. If you restart services, change configuration and delete files together, you will not know which change fixed the problem or caused a new one.
Try it yourself
On a practice virtual machine, install a simple web service, stop it and make it fail by filling the disk or changing its port. Diagnose each failure using only systemctl, journalctl, df and ss, and write the steps you took.
Your implementation checklist
- I check service state before restarting
- I read the logs for the failing time window
- I check CPU, memory and disk space
- I confirm the service listens and responds locally
- I change one thing at a time and record it
Share or cite this guide
Innovate with Ajay Editorial (2026-10-07). Read Linux Logs and Processes When a Server Misbehaves. https://innovatewithajay.com/blogs/read-linux-logs-and-processes