Linux Log Files: Where They Are and How to Read Them

When something goes wrong on a server, the explanation is already written down somewhere. The skill is knowing which file, and how to read a lot of it quickly. Here is the map for a typical web server, plus the handful of commands that turn a gigabyte of log into an answer.

System logs

journalctl — on any systemd server, the first place to look:

sudo journalctl -p err -b            # all errors since boot
sudo journalctl -u nginx -n 100      # one service
sudo journalctl --since "30 min ago"
sudo journalctl -k                   # kernel: disk errors, OOM kills, hardware

/var/log/syslog (Ubuntu/Debian) or /var/log/messages (EL) — the general system log as a text file; cron runs, service starts, kernel messages.

/var/log/auth.log (Ubuntu/Debian) or /var/log/secure (EL) — every login, sudo use and SSH attempt. Where you see who is trying to break in:

sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

/var/log/kern.log — kernel only. /var/log/dpkg.log / /var/log/dnf.log — what was installed and when, useful for "what changed yesterday".

Web server

Nginx: /var/log/nginx/access.log and error.log; per-site if configured with access_log in the server block.

Apache: /var/log/apache2/ (Ubuntu) or /var/log/httpd/ (EL).

Plesk: per domain, /var/www/vhosts/example.com/logs/ — access_ssl_log, error_log, proxy_access_ssl_log (Nginx in front), and the same files are viewable under Logs on the domain card with live tail and filters.

The error log is where 500 errors explain themselves; the access log is where you count requests, find the URL being hammered, or see the status code a visitor actually got.

# most requested URLs today
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head
# status code breakdown
awk '{print $9}' access.log | sort | uniq -c | sort -rn
# who is hitting wp-login
grep wp-login.php access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

PHP

PHP-FPM: /var/log/php8.3-fpm.log (Ubuntu) or /var/log/php-fpm/error.log (EL) — pool start/stop, "server reached max_children", worker crashes. The application's own PHP errors go where error_log points: the site's error_log on Plesk, or Nginx's error log via FastCGI. The slow log, if enabled, is next to it — see PHP-FPM tuning.

WordPress: wp-content/debug.log when WP_DEBUG_LOG is on. Laravel: storage/logs/laravel.log.

Database

MySQL/MariaDB: /var/log/mysql/error.log (Ubuntu) or /var/log/mariadb/mariadb.log (EL); journalctl -u mariadb for start/stop. The slow query log lives wherever slow_query_log_file points.

Mail

Postfix: /var/log/mail.log (Ubuntu) or /var/log/maillog (EL). Every message in and out, with a queue ID you can follow through delivery:

sudo grep "to=<someone@example.com>" /var/log/mail.log | tail

status=sent, deferred (will retry — read the reason), or bounced (gave up — the reason is the receiver's rejection message).

Plesk

/var/log/plesk/panel.log — the panel itself. /var/log/plesk/httpsd_access_log — logins to the panel. Tools & Settings → Action Log shows who changed what.

Reading fast

tail -f file.log                        # live
tail -n 500 file.log | less             # last 500, paged (/ to search, q to quit)
grep -i "error" file.log | tail -50     # errors, most recent last
grep -c "POST /wp-login" access.log     # count
zgrep "pattern" file.log.*.gz           # search rotated, compressed logs too
grep "Sep 10 14:" file.log              # a specific hour

Timestamps are the trick to cross-referencing: an error in PHP at 14:02:17 lines up with a request in the access log at 14:02:17 and perhaps an OOM kill in journalctl -k at the same second. That alignment is usually the whole diagnosis.

Rotation

Logs are rotated by logrotate (/etc/logrotate.d/): renamed with a number or date, compressed, and deleted after N rotations. A log that grew to gigabytes was not being rotated — add or fix its entry, and see finding what fills the disk. Plesk rotates per-domain logs under Logs → Log Rotation.

On a VPSPioneer managed VPS, the logs are ours to read when you open a ticket — "the site was slow at 2pm" gets answered from the access log, the PHP slow log and the resource graphs lined up by timestamp, which is exactly the process above.