How to Check Logs on a Debian Server

On modern Debian servers (Debian 12 “bookworm”, Debian 13 “trixie”, and later), the default logging system is systemd-journald. This replaced traditional plain-text log files like /var/log/syslog, /var/log/messages, and /var/log/auth.log as the primary method in minimal/base installations.

• rsyslog is now optional (not installed by default in clean installs since Debian 12).
• Most system and service logs go directly to the binary journal.
• You access them using the journalctl command — it’s powerful, filterable, and usually the first tool you reach for on a Debian server.

Quick Start: Most Common Commands

Run these as your sudo-enabled user or root.

1. View all logs (newest first, paginated)
   Bash

   journalctl

   → Use arrow keys / PgUp/PgDn to scroll, q to quit (like less).

2. Follow logs in real time (like tail -f)
   Bash

   journalctl -f

3. Show logs only from current boot
   Bash

   journalctl -b

4. Logs from previous boot (useful after crashes/reboots)
   Bash

   journalctl -b -1

   → -2 for two boots ago, etc.

5. Logs for a specific service/unit (most frequent use case)
   Bash

   journalctl -u ssh.service          # SSH daemon
   journalctl -u nginx                # Nginx (if installed as nginx.service)
   journalctl -u postgresql           # PostgreSQL
   journalctl -u docker               # Docker daemon

6. Combine filters — current boot + specific service + follow live
   Bash

   journalctl -u nginx -b -f

Useful Filtering Examples for Servers

Classic /var/log Files — Do They Still Exist?

• In a minimal server install → usually no/var/log/syslog, /var/log/auth.log, etc.
• If you installed rsyslog (or it was pulled in as a dependency): → Yes — traditional files reappear in /var/log/ → journald still receives everything (messages are duplicated unless you tune journald)

To restore classic text logs (optional):

sudo apt update
sudo apt install rsyslog
sudo systemctl enable --now rsyslog

After this, check /var/log/syslog, /var/log/auth.log, etc. again.

Quick Troubleshooting Workflow (Typical Server Scenarios)

1. Something isn’t working? Start here:
   Bash

   journalctl -u your-service-name -xe

   → -x adds explanatory help text, -e jumps to the end

2. See what just happened after a failed restart:
   Bash

   journalctl -u nginx -b -p err..emerg

3. Check entire boot process for slow/critical parts:
   Bash

   journalctl -b -p warning..emerg
   # or analyze boot time
   systemd-analyze blame

4. Watch for brute-force attacks or weird logins:
   Bash

   journalctl -u ssh -f | grep -i "failed\|invalid\|bad"

Bonus: Make journalctl Even Better

• Use colors and short output (default is usually good, but you can force):
  Bash

  journalctl --no-pager -o short-precise

• Limit journal size to prevent disk filling (edit /etc/systemd/journald.conf):
  text

  [Journal]
  SystemMaxUse=500M
  SystemKeepFree=2G

  Then: sudo systemctl restart systemd-journald

On a Debian server, mastering journalctl is one of the highest-ROI skills — it gives you centralized, structured, queryable logs without needing extra tools in 90% of cases.