System Log Files (/var/log)

When something breaks on a Linux server, the answer is almost always written down somewhere. That “somewhere” is usually /var/log, the traditional directory where the operating system and most applications record what they are doing. A log file (a plain-text file that programs append messages to as events happen) is the first place a system administrator looks to diagnose a problem. This page tours the most important files in /var/log on Ubuntu, shows you how to read them live, and explains exactly which file to open for which kind of problem.

What is /var/log?

/var/log is a standard directory that exists on every Linux system. The /var part means “variable data” (files that grow and change while the system runs), and log holds the logs. Most files there are plain text, so you can read them with ordinary tools like cat, less, tail, and grep.

Let’s see what is inside on a typical Ubuntu 22.04/24.04 server.

ls -lh /var/log

Output:

-rw-r-----  1 syslog adm   1.2M Jun 15 09:14 auth.log
-rw-r-----  1 syslog adm   4.8M Jun 15 09:14 syslog
-rw-r-----  1 syslog adm   220K Jun 15 09:10 kern.log
drwxr-x---  2 root   adm   4.0K Jun 15 00:00 nginx
drwxr-xr-x  2 root   root  4.0K Jun 14 12:30 apt
-rw-rw-r--  1 root   utmp   58K Jun 15 09:14 wtmp
-rw-r--r--  1 root   root   31K Jun 15 08:00 dpkg.log

Notice many log files are owned by group adm with mode 640, so you need sudo (or membership in the adm group) to read them. Trying without sudo gives “Permission denied” — that is normal, not a broken system.

The key log files

Here are the files you will reach for most often, and what each one is for.

File	What it records	Open it when…
/var/log/syslog	General system messages from almost everything	You want the big picture of what the system did
/var/log/auth.log	Logins, sudo use, SSH activity, authentication	You suspect a login problem or a break-in attempt
/var/log/kern.log	Messages from the Linux kernel itself	Hardware, drivers, disk errors, or the system froze
/var/log/dpkg.log	Every package install/remove via dpkg/apt	You need to know when a package was installed
/var/log/apt/history.log	High-level apt command history	”What did the last apt upgrade actually change?”
/var/log/nginx/access.log	Every HTTP request to your Nginx web server	Checking traffic or a specific request
/var/log/nginx/error.log	Nginx errors (bad config, upstream failures)	Your website returns 502/500 errors

Modern Ubuntu also collects most of this in the journal (a structured binary log managed by systemd, read with journalctl). /var/log and the journal overlap, but plain-text files in /var/log are still the simplest way to read app logs like Nginx. See the journalctl page linked at the bottom.

Reading a log file

A log file can be huge, and you usually only care about the newest lines (the bottom of the file). tail prints the last lines of a file.

sudo tail -n 50 /var/log/syslog

Output:

Jun 15 09:14:01 web01 CRON[20431]: (root) CMD (/usr/local/bin/backup.sh)
Jun 15 09:14:02 web01 systemd[1]: Started Session 88 of user deploy.
Jun 15 09:14:05 web01 nginx[812]: 203.0.113.7 - - "GET /health HTTP/1.1" 200

The -n 50 means “show the last 50 lines.” To watch a log update in real time, add -f (follow). This is the single most useful command for debugging — run it, then trigger the action you are testing, and watch the messages appear.

sudo tail -f /var/log/nginx/access.log

Press Ctrl+C to stop following.

Searching with grep

When you know roughly what you are looking for, grep (a tool that prints only the lines matching a pattern) is faster than scrolling.

sudo grep "Failed password" /var/log/auth.log

Output:

Jun 15 08:59:12 web01 sshd[19022]: Failed password for invalid user admin from 198.51.100.23 port 54122 ssh2
Jun 15 08:59:15 web01 sshd[19022]: Failed password for invalid user root from 198.51.100.23 port 54122 ssh2

Combine grep with tail -f to watch only matching lines live:

sudo tail -f /var/log/auth.log | grep --line-buffered "sshd"

The --line-buffered flag makes grep print each match immediately instead of waiting to fill a buffer.

Which log for which problem

This is the part most tutorials skip. Match the symptom to the file.

• Can’t log in over SSH, or worried about brute-force attacks -> /var/log/auth.log. Search for Failed password, Accepted password, or sudo.
• A sudo command was run and you want to know who/when -> /var/log/auth.log. Look for sudo: and COMMAND=.
• The whole system feels slow or a service died unexpectedly -> /var/log/syslog first, then /var/log/kern.log for hardware/disk issues.
• Disk errors, network card resets, “Out of memory” kills -> /var/log/kern.log. The kernel logs the OOM (Out Of Memory) killer here when it terminates a process to free RAM.
• Your website is down or showing errors -> /var/log/nginx/error.log for why, /var/log/nginx/access.log for who.
• A package broke after an update -> /var/log/apt/history.log to see exactly what changed and when.

For example, to find who used sudo today:

sudo grep "sudo:" /var/log/auth.log | grep "COMMAND"

Output:

Jun 15 09:02:44 web01 sudo:   deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

Log rotation

Log files would grow forever, so Ubuntu automatically rotates them with a tool called logrotate. Rotation means the current file (e.g. syslog) is renamed to syslog.1, then syslog.2.gz, and a fresh empty syslog is started. Older files are compressed with gzip (.gz) and eventually deleted.

To read a compressed, rotated log without un-zipping it first, use zcat, zless, or zgrep:

sudo zgrep "Failed password" /var/log/auth.log.2.gz

The rotation rules live in /etc/logrotate.conf and /etc/logrotate.d/. If logs are filling your disk, this is where you shorten how long they are kept.

# /etc/logrotate.d/nginx (excerpt)
/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
}

Here rotate 14 keeps 14 days of rotated logs; lower it to save disk space.

Best Practices

• Start with tail -f on the relevant log, then reproduce the problem so you see the error appear in real time.
• Learn the symptom-to-file map above; jumping straight to the right log saves minutes every time.
• Use grep (and zgrep for .gz files) instead of scrolling — it finds needles in million-line haystacks instantly.
• Never rm a busy log file to free space; truncate it with sudo truncate -s 0 /var/log/big.log so the writing process keeps working, or fix logrotate.
• Watch auth.log for Failed password floods — repeated failures from one IP are a brute-force attack; block it with ufw or install fail2ban.
• Keep an eye on /var/log disk usage with sudo du -sh /var/log/* so runaway logs don’t fill the partition.

Related Topics

• Viewing logs with journalctl
• sudo and root
• Checking disk usage
• Managing systemd services
• Monitoring resources