A safe troubleshooting mindset
Troubleshooting is not guessing commands until something changes. It is narrowing the problem: what changed, what layer is failing, what evidence exists, and what is the smallest safe test?
Write down exact errors before changing things. Prefer read-only inspection first. Make backups before editing configuration. Change one variable at a time.
Where logs live
Modern systemd distributions store many logs in the journal, queried with journalctl. Traditional logs also appear under /var/log. Applications may log to files, the journal, containers, or their own data directories.
| Log source | Where to look |
|---|---|
| systemd services | journalctl -u service-name |
| Current boot | journalctl -b |
| Kernel messages | journalctl -k or dmesg |
| Traditional logs | /var/log |
| Application-specific logs | Application docs, /var/log/app, /var/lib/app, container logs |
journalctl basics
journalctl can filter by service, boot, priority, time, executable, user, and more. Targeted filters are usually more useful than scrolling through everything.
journalctl -bjournalctl -u nginx --since "30 minutes ago"journalctl -fjournalctl -p err -bCommon Linux problems and first checks
| Problem | First checks |
|---|---|
| Permission denied | whoami, id, ls -l, directory execute bits, sudo need |
| Package install fails | Network, repository metadata, held packages, disk space, conflicting repos |
| Service will not start | systemctl status, journalctl -u, config syntax, port conflicts |
| Boot issue | journalctl -xb, systemctl --failed, fstab entries, recent kernel or driver changes |
| Networking issue | ip addr, ip route, DNS test, ping, curl, ss, firewall |
| Disk full | df -h, du -h -d 1, logs, caches, snapshots, container images |
How to read error messages
An error often contains the failing operation, target path or service, reason, and sometimes the file and line number. Do not search only the final generic line if there is a more specific line above it.
For permission errors, identify the user, target file, parent directories, and desired operation. For network errors, separate DNS errors from connection refused, timeout, TLS failures, and HTTP status codes.
Practical debugging steps
- 1Reproduce the issue once and copy the exact error.
- 2Identify the layer: file, permission, package, service, network, disk, boot, or application.
- 3Inspect state with read-only commands first.
- 4Check logs close to the time of failure.
- 5Make a reversible change.
- 6Test again and compare evidence.
- 7Keep notes so you can undo or explain what changed.