When something goes wrong on a server, the answer is almost always in the logs. Logs are records that tell what the system, services and applications did. Knowing how to read logs is the difference between guessing a problem and diagnosing it. This guide explains where Linux logs are kept and how to read them.

Related reading: Essential Linux server commands · systemd service management · Server monitoring basics

Where Are Logs Kept on Linux?

Traditionally, logs are kept as plain text files in the /var/log/ directory. On modern systemd-based systems, logs are also collected in a structured record system called the journal and read with journalctl.

LocationContent
/var/log/syslogGeneral system events (Debian/Ubuntu)
/var/log/auth.logAuthentication, SSH logins, sudo
/var/log/nginx/Nginx access and error logs
/var/log/apache2/Apache access and error logs
journalctlCentral logs of systemd services

Reading Logs with journalctl

systemd's journalctl command is the most powerful tool for reading logs. You can filter by a specific service, time range or priority level:

# See a specific service's logs
journalctl -u nginx

# Follow logs live
journalctl -u nginx -f

# Only the last 1 hour
journalctl --since "1 hour ago"

# Only error priority and above
journalctl -p err

Reading Plain-Text Logs

To read the text files under /var/log/, basic commands are enough: tail -f follows the file live, less shows it page by page, and grep searches for a specific text or error.

# Follow the Nginx error log live
tail -f /var/log/nginx/error.log

# Search for 404 errors in the access log
grep " 404 " /var/log/nginx/access.log

# Find failed SSH logins in auth.log
grep "Failed password" /var/log/auth.log

Diagnosing Problems with Logs

When diagnosing a problem from logs, be methodical: first determine when it started, then inspect the logs in that time range. If a service crashed, the lines just before the crash usually show the cause. If you do not know the error message, searching for the message as-is often points you in the right direction.

Tip
A web server's access log and error log tell different things: the access log shows who requested what, the error log shows what went wrong. When diagnosing a problem, look at the error log first.

Log Rotation (logrotate)

Logs grow constantly and, if unchecked, fill the disk. This is why the logrotate tool exists: it archives log files at regular intervals, compresses them and deletes old ones. On most distributions logrotate comes pre-configured; you can add a rule for your own application logs too.

Frequently Asked Questions

Does journalctl fill up the disk?

The journal has a size limit and automatically cleans old records. You can set the limit with SystemMaxUse in the /etc/systemd/journald.conf file.

The log file is huge, how do I open it?

Do not open large files with cat — it strains the system. less loads the file in chunks; tail shows the end, and grep brings only the lines you are looking for.

Where is my application log?

If your application runs as a systemd service, its logs appear with journalctl -u service-name. If the application writes to its own file, that path is usually defined in the application's configuration.

A Transparent, Observable Server

With KEYDAL hosting solutions, see what is happening on your server at any moment with log access and monitoring tools. Explore KEYDAL hosting

WhatsApp