When a website stops opening, a service will not start or the server behaves strangely, the first thing to do is look at the logs. Almost everything that happens on a server is written down somewhere. The hard part is knowing where exactly to look and how to quickly find what you need among thousands of lines. In this article we look at where logs are stored on a modern Linux system, learn to use the journalctl command, find errors and attempts to guess the SSH password, look at Nginx logs and see how to keep logs from filling up the whole disk. All examples were made on a test server with Debian 12.
Where Linux stores logs
For a long time, logs in Linux were ordinary text files in the /var/log directory. They were written by the syslog service. Messages about logins to the server went to the auth.log file, general system messages went to syslog, and each program could also keep files of its own. This approach is simple and clear, but it has drawbacks. To find out what happened to a particular service at a certain hour, you had to search through several files, and the line format differed from one program to another.
Systems with systemd introduced a single journal. It is kept by the systemd-journald service, which collects messages from the kernel, from system services and everything that programs running as services print to the console. Each entry is stored together with information about which service created it, with what priority and during which server boot. Thanks to this, the journal can be filtered by service, time or severity level with a single command, without going through files. The journal is stored in binary form in the /var/log/journal directory, so you read it not with a text editor but with the journalctl command.
Our servers with Debian 12 have no classic syslog service, and the journal remains the only place for system logs. That is why you will not find the familiar /var/log/syslog and /var/log/auth.log files there, as the /var/log/README file warns. At the same time, many programs still write their own text logs to /var/log. For example, Nginx keeps the access.log and error.log files in the /var/log/nginx folder. So the server has two kinds of logs, and each of them needs its own way of reading.
1. Read the journal with journalctl
Without parameters, journalctl prints the whole journal starting from the oldest entries, and that is usually far too much. Below are the commands you will need most often.
# Last 50 lines of the whole journal
journalctl -n 50
# Follow new entries in real time, press Ctrl+C to exit
journalctl -f
# Entries of a specific service
journalctl -u nginx
# Entries for the last hour or for a certain period
journalctl --since "1 hour ago"
journalctl --since "2026-10-21 10:00" --until "2026-10-21 10:30"
# Only since the current server boot
journalctl -bParameters can be combined. For example, journalctl -u ssh --since today shows all entries of the SSH service for today. If the output does not fit on the screen, journalctl opens it in a pager. You can scroll with the arrow keys, search for text with the / key and exit with the q key.
2. Find errors
Every journal entry has a priority. The -p err parameter keeps only errors and more serious messages, and together with -b only those that appeared since the last boot.
journalctl -p err -b
Only errors since the server booted
If a specific service is not working, start with its status and the last lines of its log. How to do this is explained in detail in the article about systemd services.
systemctl status nginx
journalctl -u nginx -n 503. Check who is trying to log in over SSH
Any server with an open SSH port is constantly attacked by programs that try passwords one after another. You can see this in the journal of the ssh service.
journalctl -u ssh --since "1 hour ago" | grep -E "Failed password|Invalid user"
Password guessing for root and for non-existent users, addresses hidden
On our test server, 2510 such lines piled up in the journal in a single day. This is ordinary internet background noise rather than an attack aimed at you, but it shows well why password login is better replaced with an SSH key and why password guessing should be blocked. How to do this is explained in the articles about SSH keys and fail2ban.
The lastb command shows a shorter list of failed logins, and the last command shows the successful ones.
lastb -n 10
last -n 104. View the logs of Nginx and other programs
Programs that keep their own logs usually write them to a separate folder inside /var/log. For Nginx, these are two files.
- access.log contains a line for every request to the site, with the visitor's IP address, the page address and the response code.
- error.log contains errors, for example denied access to a file or an unavailable backend.
# Last lines and following in real time
tail -n 50 /var/log/nginx/error.log
tail -f /var/log/nginx/access.log
# Find requests in the log that the site answered with a 502 error
grep '" 502 ' /var/log/nginx/access.logText logs do not grow forever. Every day the logrotate program renames and compresses them. For Nginx on the test server it is set to keep logs for 14 days, and it puts the older parts next to the current one in files like access.log.1 and compressed access.log.2.gz. You can read compressed files with the zcat and zgrep commands.
5. Free up the space that logs take
You can see how much space the journal and the log folders take with two commands.
journalctl --disk-usage
du -sh /var/log/* | sort -h | tail
The journal takes 24 MB, which is most of /var/log
If the journal has grown too large, you can shrink it to the size you need or delete entries older than a certain age. Only old archived parts are deleted, and the current entries stay.
# Keep the journal no larger than 500 MB
journalctl --vacuum-size=500M
# Delete entries older than two weeks
journalctl --vacuum-time=2weeksTo keep the journal from growing again, set a limit in the /etc/systemd/journald.conf file, for example with the line SystemMaxUse=500M, and restart the service with systemctl restart systemd-journald.
Do not delete logs with rm
If a program keeps a log file open, after rm it will go on writing to the already deleted file, and the disk space will not be freed. To clear a large text log, empty it with truncate -s 0 /var/log/nginx/access.log.
Frequently asked questions
No such file or directory: /var/log/syslog
The server has no syslog service, and system messages are stored only in the journal. Read them with the journalctl command. If you specifically need text files, install rsyslog with apt install -y rsyslog, and it will keep classic log files alongside the journal.
journalctl does not show all entries
A regular user sees only their own entries. Run journalctl as root or through sudo, or add the user to the adm group.
The time in the log differs from mine
Logs are written in the server's time zone. On our servers it is Europe/Berlin. You can check the time zone with the timedatectl command, and the journalctl --utc parameter lets you view entries in UTC.
Our resources
Telegram channel: https://t.me/f3cloud_news
F3 Cloud: https://f3cloud.com