linux troubleshooting guide

Reading Linux Logs: A Beginner Troubleshooting Method

Logs become manageable when you narrow by service, time, severity words, and surrounding context instead of opening the whole file.

Problem

A service fails, but logs are long, noisy, and spread across files or the system journal. You need a repeatable way to find the first useful error.

First rule

Narrow the log before reading it: service, time window, likely failure terms, then context.

Audience

Linux beginners, help desk analysts, junior admins, and command-line certification students

Cert context

Helpful for unofficial LPIC-1, LFCS, and Linux+ practice around logs, pipes, grep, service diagnosis, and text processing.

quick start

Safe first commands

journalctl -u nginx --since '30 minutes ago' --no-pager
tail -n 80 /var/log/nginx/error.log
grep -inE 'error|failed|denied|timeout' /var/log/nginx/error.log
grep -iE 'error|failed|denied|timeout' /var/log/nginx/error.log | tail -40

Start with the service and time window

If the service is managed by systemd, `journalctl -u` keeps you out of unrelated machine-wide noise. A time window also prevents old errors from stealing attention.

journalctl -u nginx --since '30 minutes ago' --no-pager
journalctl -u nginx -b --no-pager

Use tail when the file is the source of truth

Some applications still write the most useful details to files under `/var/log`. Use `tail` for recent lines and `tail -f` only while reproducing the failure.

tail -n 80 /var/log/nginx/error.log
tail -n 80 -f /var/log/nginx/error.log

Search for likely failure words

A first grep pass is not proof, but it quickly finds candidates such as permission denials, timeouts, failed connects, and syntax errors.

grep -iE 'error|failed|denied|timeout|refused' /var/log/nginx/error.log | tail -40

Use line numbers before scrolling

Line numbers make it easier to inspect nearby context and share precise findings with someone else.

grep -inE 'error|failed|denied|timeout' /var/log/nginx/error.log

triage logic

How to read the result

journal output has start or reload errors

The service manager saw the failure, often with a useful status code or config message.

Next: Read the lines immediately before the failure, not only the final summary.

file logs show permission denied

The service may not be able to read a file or traverse a directory.

Next: Inspect ownership and path permissions before using chmod.

logs show timeout or refused

The next layer may be a network listener, upstream service, or firewall path.

Next: Check ports and service state.

safety notes

Slow down here

Be careful sharing logs; they can contain tokens, IPs, paths, and user data.
Do not paste secrets into public troubleshooting threads.
Prefer read-only log commands during initial triage.

related lessons