Strategies for Troubleshooting Common Linux Problems With System Logs
A Linux service stops responding, a server reboots unexpectedly, or an update breaks an application.
Restarting everything may restore access, but it rarely explains what happened. System logs provide the timeline needed to identify failures, test a diagnosis, and verify repairs. Effective Linux troubleshooting starts with a focused question: what changed immediately before the problem appeared?
By selecting the right log source and narrowing the search, you can replace guesswork with evidence.
Find the Right Logs Before Investigating
On systems running systemd, journald collects messages from services, the kernel, and other sources. Read these records with journalctl; journal files are not ordinary text files. Applications may also maintain separate logs under /var/log, while syslog services can route messages into distribution-specific files.
The Red Hat log troubleshooting guide explains how journal entries and traditional log files support diagnosis. File availability depends on installed software and logging configuration, so confirm what exists locally rather than assuming every distribution uses identical paths.
| Problem | Useful starting point | What to investigate |
| Failed service | journalctl -u nginx.service -b | Startup errors and missing dependencies |
| Unexpected reboot | journalctl -b -1 | Events preceding the previous shutdown |
| Kernel or hardware issue | journalctl -k -b | Driver warnings and device errors |
| Authentication failure | Authentication journal entries or configured security logs | Rejected credentials and access restrictions |
| Application failure | Application-specific logs | Exceptions and configuration errors |
Replace nginx.service with the actual unit name. Use sudo when your account lacks permission to read the required records. Restricted access can produce an incomplete picture rather than proof that nothing happened.
Narrow the Search by Time, Boot, and Severity
Reading an entire journal is rarely productive. Record when the symptom appeared, including the server’s timezone, then inspect a short interval around that moment. Start with sudo journalctl -b –since “30 minutes ago” –no-pager to review recent messages from the current boot.
For a specific service, use sudo journalctl -u nginx.service –since “30 minutes ago” –no-pager. To surface serious failures, run sudo journalctl -b -p err. This includes error messages and more severe priorities, not errors alone.
The official journalctl manual documents these filters and how they combine.
Do not stop at the last error. A failed connection may follow an earlier service crash, and a shutdown message may simply describe the result. Expand the time window and remove the severity filter when important context is missing.
Use this investigation sequence:
- Record the symptom, affected service, and approximate start time.
- Select the relevant boot and a narrow time window.
- Find the first meaningful failure, not just repeated complaints.
- Compare nearby service and kernel messages.
- Test one explanation, then review fresh logs.
Diagnose Common Linux Failures
Services That Refuse to Start
Check systemctl status nginx.service, then inspect the unit’s journal. Look for an invalid configuration, unavailable file, occupied port, or failed dependency. A message stating that a process exited is a starting point; the preceding application message often explains why.
If the log identifies a configuration problem, use the application’s configuration checker where available. Correct the reported issue before restarting. Avoid repeatedly restarting a service without preserving the original error and noting what you changed.
Boot Failures and Unexpected Restarts
Run sudo journalctl –list-boots to see which boots remain available, then inspect the relevant boot with sudo journalctl -b -1. Previous-boot analysis requires retained records; missing output does not establish that the earlier session was healthy.
Compare the final messages with the next startup. An orderly shutdown and an abrupt end suggest different investigation paths, but neither alone proves the cause. Power loss, storage failure, and crashes may leave incomplete records.
Storage and Memory Problems
Review kernel entries with sudo journalctl -k -b. Messages about input/output errors, filesystem problems, or memory pressure can help narrow the investigation. Correlate them with resource checks rather than treating every warning as a confirmed hardware failure.
For example, check filesystem capacity and inode availability when an application cannot write files. If a process disappears during heavy load, investigate whether the kernel reported an out-of-memory kill. Deleting logs immediately can destroy the evidence needed to distinguish these problems.
Preserve Evidence and Verify the Fix
Before changing configuration, save the relevant interval using sudo journalctl -u nginx.service –since “30 minutes ago” > incident.log. Review exported records for credentials, tokens, personal information, and internal addresses before sharing them.
Follow new service messages with sudo journalctl -u nginx.service -f while reproducing the original failure. After applying a targeted correction, repeat the same operation and confirm both normal behavior and the absence of recurring errors.
Check retention before the next incident. Volatile journals disappear after reboot; persistent storage preserves records on disk, subject to retention limits. Set appropriate storage limits so logging remains useful without consuming excessive space.
Keep a short incident record containing the symptom, relevant timestamps, confirmed cause, corrective action, and verification results for future reference during similar failures.
Build Confidence Through Evidence
Reliable troubleshooting rewards discipline, not dramatic fixes. Each carefully chosen filter, preserved error, and verified correction makes the next investigation easier. Learn to read the sequence behind a failure, and Linux logs become a practical record of how your system behaves—and how to restore it with confidence.
