Reading your VPS logs — journalctl, dmesg, /var/log, what matters when

Every troubleshooting article tells you to "check the logs." This article tells you which log, with what flag, looking for what. A practical tour of the places things actually get logged on a modern Linux VPS.

The big three

journalctl — the systemd journal

Almost every system service on a modern distro writes to the journal. Universal entry point:

# Recent journal entries from all services
journalctl --since "1 hour ago"

# Tail in real time
journalctl -f

# A specific service
journalctl -u sshd

# Errors and worse only
journalctl -p err --since today

# Around a specific time
journalctl --since "2026-06-18 09:00" --until "2026-06-18 09:30"

Notable flags:

• -x — add context to error messages where available.
• -b — only the current boot. -b -1 for the previous boot.
• --no-pager — useful for piping or scripting.
• -r — newest first (default is oldest first).

dmesg — the kernel ring buffer

Kernel messages: hardware events, driver issues, OOM kills, network interface state changes. Most of this also lands in journalctl, but dmesg is faster and easier for kernel-specific issues.

# Recent kernel messages with human time
dmesg -T | tail -100

# Watch in real time
dmesg -wT

# Errors only
dmesg -lerr,warn

If a VM is misbehaving and you suspect the kernel or hardware, dmesg before anything else.

/var/log/* — service-specific files

Many services still write to /var/log directly, either alongside or instead of the journal:

• /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RPM) — authentication events. SSH logins, sudo, pam.
• /var/log/syslog (Debian/Ubuntu) — general syslog (mostly mirrored in journal).
• /var/log/messages (RPM) — same role as syslog.
• /var/log/mail.log or /var/log/maillog — Postfix / Dovecot / Exim activity.
• /var/log/nginx/access.log, error.log — nginx specifics.
• /var/log/apache2/ or /var/log/httpd/ — Apache.
• /var/log/asterisk/full — Asterisk everything; the big PBX log.
• /var/log/asterisk/messages — Asterisk warning+ only.

What to look for, by symptom

"My VPS feels slow"

1. journalctl -p err --since "1 hour ago" — look for OOM, disk, network errors.
2. dmesg -T | tail -50 — kernel-side issues.
3. journalctl -u systemd-journald — sometimes journald itself drops messages when overloaded.

"I can't SSH in"

1. Browser console → journalctl -u sshd --since "10 minutes ago".
2. Look for "Failed password" (auth failure), "Connection closed by user" (your client gave up), or no entries at all (sshd isn't running or isn't seeing your traffic).
3. /var/log/auth.log for the same info on older systems.

"Mail isn't going out"

1. tail -200 /var/log/mail.log — look for the message ID of your test mail.
2. Look for "deferred", "bounced", "warning:" entries following the message ID.
3. If you don't see your message at all, the MTA didn't receive it (Asterisk-pipe issue, postdrop issue).

"My web service is throwing 500s"

1. tail -f /var/log/nginx/error.log while triggering a 500.
2. If the error log is silent, the 500 is coming from the application (PHP-FPM, the Python app, etc.) — check its own log.
3. journalctl -u php-fpm if running PHP-FPM.

"A service died and I don't know why"

1. systemctl status <service> — shows the last 10 journal lines for the service.
2. journalctl -u <service> --since "1 hour ago" — full context.
3. If the service kept crashing on start: journalctl -xeu <service>.

Disk-saver — what NOT to grep

The whole journal can be huge. Avoid:

• journalctl | grep foo without a time filter — pages through everything, slow and memory- hungry.
• tail -F /var/log/syslog as a "monitoring" tool — use it for one minute at a time; for ongoing watching, use a proper log aggregator (Netdata, Promtail, etc.).

Prefer:

• Time filters: --since / --until.
• Service filters: -u <name>.
• Priority filters: -p err.

Log rotation

Both systemd journal and traditional logs rotate automatically. Defaults are reasonable but worth knowing:

• Journal size cap: in /etc/systemd/journald.conf, SystemMaxUse (default ~10% of /var).
• Traditional log rotation: /etc/logrotate.d/. Each service has its own config. Default rotation is weekly with 4 generations kept.

If logs are eating disk, check du -sh /var/log/* and look for the outlier. Common offenders: Asterisk full log on a heavy PBX, application logs without rotation, debug logs left on after a troubleshooting session.

Sending logs off-VPS

For ongoing operational visibility, ship logs somewhere central:

• Netdata Cloud — bundled with the Netdata agent; modest log forwarding included. See Netdata quickstart.
• Loki + Promtail — open-source, scales well, plays nicely with Grafana.
• Syslog forwarding to a central rsyslog/syslog-ng — simple, works.

For a single VPS, log-on-box is usually enough. For multiple VPSes, centralisation pays for itself the first time you need to correlate an event across two boxes.