Linux Log Files: Where to Look When Your Server or Site Misbehaves

When a site returns an error, a service refuses to start or the server slows down, the answer is almost always written down somewhere. Linux logs a great deal, but beginners often do not know which file to open. This guide maps common questions to the right log and shows the commands to search through them efficiently.

The two logging worlds: files and the journal

Traditionally, services write plain text files into /var/log. Modern distributions that use systemd also collect output into the journal, a binary log you read with journalctl. Many systems have both: web servers still write their own files, while system services and your own systemd units log to the journal. Knowing which place to check is half the job.

The files you will open most

Question	Where to look
General system messages	/var/log/syslog (Debian/Ubuntu), /var/log/messages (Red Hat style)
Who logged in, sudo use, SSH failures	/var/log/auth.log (Debian/Ubuntu), /var/log/secure (Red Hat style)
Nginx requests and errors	/var/log/nginx/access.log and error.log
Apache requests and errors	/var/log/apache2/ (Debian/Ubuntu), /var/log/httpd/ (Red Hat style)
Database problems	Often /var/log/mysql/error.log or /var/log/postgresql/
Kernel messages, hardware, out-of-memory kills	dmesg or journalctl -k
Scheduled jobs	The cron lines in syslog, or journalctl -u cron

Paths vary a little between distributions and installation methods. If you cannot find a log, check the service's configuration for log directives. On servers managed with Plesk, each website also has its own logs, viewable in the panel and stored in the domain's logs folder, usually under /var/www/vhosts/.

Reading files and the journal

Reading and following files

Start with the end of the file, since the newest entries are at the bottom:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -f /var/log/nginx/error.log
sudo less +F /var/log/syslog

tail -f follows new lines as they arrive, so you can reproduce the problem in your browser and watch the error appear. In less +F mode, press Ctrl+C to stop following and search, and F to resume. To search, use grep:

sudo grep -i "error" /var/log/nginx/error.log | tail -20
sudo zgrep "198.51.100.7" /var/log/nginx/access.log.*.gz

The second command searches compressed, rotated logs. Because older logs are rotated and compressed, the evidence for something that happened last week may be in one of those archives.

When a service dies without any obvious error, ask the kernel. If the machine ran out of memory, Linux's out-of-memory killer ends a process and records it:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -k | grep -i "killed process"

Either command printing a line naming your database or application explains an otherwise silent crash and tells you the server needs more memory, swap or a lighter configuration.

Using journalctl

The journal is searchable by service, time and severity:

sudo journalctl -u nginx --since "1 hour ago"
sudo journalctl -u myapp -f
sudo journalctl -p err -b
sudo journalctl --disk-usage

These show one service's last hour, follow a service live, list errors since the last boot, and report how much disk the journal uses. Add -n 200 to limit output and --no-pager when piping to another tool. If a service will not start, systemctl status name usually shows the last few log lines, and journalctl -xeu name adds context and explanations.

Quick analysis of web access logs

Nginx and Apache default log formats put the HTTP status code in the ninth space-separated field. To count responses by status code:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

A rising number of 5xx codes points at the application or backend; many 404s may be broken links or scanners probing for common files. To see the busiest client addresses:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

If your site sits behind a proxy or CDN, the first field may be the proxy's address, not the visitor's, unless real client IP handling has been configured.

Rotation, privacy and habits

Log rotation, disk space and privacy

Logs grow forever unless something rotates them. The standard tool is logrotate, configured in /etc/logrotate.conf and /etc/logrotate.d/; it compresses old files and deletes them after a set number. Application logs that you create yourself need an entry there too. A full disk is a frequent cause of mysterious failures, so check with df -h, and use sudo du -sh /var/log/* to find what is large.

Access logs contain IP addresses, which privacy law can treat as personal data. Keep retention proportionate to your real needs, restrict who can read the files, and take legal advice if you are unsure about your obligations.

A habit worth building

When something breaks, note the exact time, then look at the logs around that moment, starting with the service closest to the symptom: the web server for error pages, the application for logic errors, the database for query failures, the kernel for crashes and out-of-memory kills. Correlating timestamps across files quickly shows where a failure began. Make sure your server clock and time zone are correct, or the timestamps will mislead you.

Tools that save time

When logs get big, a few tools help. less with the / search command lets you page through a file without loading it all. grep -C 5 "error" prints five lines of context around each match, which often shows what led up to a failure. For web logs, tools such as GoAccess can turn access logs into a readable report in the terminal or as a web page. And if you manage several servers, shipping logs to a central place makes it far easier to correlate events, and protects the evidence if one machine is compromised. Our security page explains why log review is part of a wider routine.

Troubleshooting with Zebra Hosting

If you get stuck reading a log, our support team can help you interpret it, in your own language. See the knowledge base for common error explanations.