What is the systemctl command to see service logs?

There is none: systemctl status shows only the last few journal lines as a courtesy. The real tool is journalctl -u , with -f to follow, -n for history depth, and --since for time windows.

Why does journalctl show no logs from before the last reboot?

The journal is in volatile mode, stored on a tmpfs under /run/log/journal and wiped at boot. Create /var/log/journal (with Storage=auto) or set Storage=persistent in /etc/systemd/journald.conf, restart systemd-journald, and history will survive reboots from then on.

How do I see only errors from a service?

journalctl -u -p err shows entries at priority err and worse (crit, alert, emerg); use -p warning to include warnings. This relies on the service logging with proper priorities: plain stdout text from an app arrives at the default info-ish priority.

How do I export journalctl output to a file?

Plain redirection works: journalctl -u api --since today > api.log. Use -o short-iso for sortable timestamps or -o json for structured processing, and --no-pager when scripting so output is not piped through less.

Is journalctl -f the same as tail -f /var/log/syslog?

Functionally similar but richer: the journal is structured and indexed, so you can follow one unit, one priority, or one boot instead of grepping a flat file. On many modern distributions the text syslog file barely exists and journald is the primary log store.

How-to

journalctl: Tail and Filter systemd Logs Like tail -f

Updated July 27, 2026

In short

The systemd equivalent of tail -f for a service is journalctl -u <service> -f, and there is no systemctl logs command, journalctl is the tool (systemctl status only shows the last few lines). Use -n 100 for the last 100 lines, --since "10 min ago" for a time window, and -p err to cut straight to errors. If logs vanish on reboot, the journal is running in volatile mode: create /var/log/journal or set Storage=persistent to keep history.

start here

journalctl -u <service-name> -f -n 100

Step 1

Step 1: follow and tail

-f follows new entries live; -n N prints the last N lines first (default 10 when combined with -e). -e jumps the pager to the end. Without any unit filter these commands show the whole system journal (kernel, services, everything) which is occasionally what you want and usually not.

journalctl -u nginx -f            # tail -f for one service
journalctl -u nginx -n 200        # last 200 lines
journalctl -f                     # everything, live

Step 2

Step 2: filter by unit, time, priority, and pattern

Filters combine: several -u flags merge units into one interleaved stream, --since/--until take natural phrases ("10 min ago", "yesterday") or timestamps, -p err shows priority err and worse, -b limits to the current boot, and -g greps message text server-side. -o json emits structured output for scripts.

journalctl -u api -u worker --since "1 hour ago"
journalctl -u nginx -p err -b
journalctl -u api -g "timeout|refused" --since today
journalctl -u api -o json --since "10 min ago" | jq .MESSAGE

Step 3

Step 3: make the journal persistent

On some distributions journald defaults to volatile storage in /run/log/journal: a tmpfs, wiped every reboot, which is why "journalctl shows nothing from before the crash". With Storage=auto (the common default), simply creating /var/log/journal switches to persistent storage; Storage=persistent in journald.conf forces it.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
# or explicitly: set Storage=persistent in /etc/systemd/journald.conf

Step 4

Step 4: keep disk usage under control

A persistent journal grows until it hits its caps (by default up to 10% of the filesystem, capped at 4G). Check usage, vacuum by size or age, and set hard limits in journald.conf with SystemMaxUse.

journalctl --disk-usage
sudo journalctl --vacuum-size=500M      # shrink to 500 MB
sudo journalctl --vacuum-time=2weeks    # drop entries older than 2 weeks
# permanent cap: SystemMaxUse=1G in /etc/systemd/journald.conf

Previous boots and kernel messages

With a persistent journal, --list-boots enumerates recorded boots and -b -1 reads the previous one: the standard way to investigate why a machine died, since the last entries before an unclean shutdown are preserved. -k (or --dmesg) filters to kernel messages, which is where OOM-killer and hardware events live.

journalctl --list-boots
journalctl -b -1 -e            # end of the previous boot
journalctl -k -b -1 | grep -i "out of memory"

Beyond the one-off fix

journald works because every process on the host writes into one indexed, queryable stream: no per-service log spelunking. AI-agent fleets need the same consolidation: an agent's actions scattered across shell history, API logs, and git blame are as useless as pre-systemd syslog fragments. Nexus is the journald of the agent layer: every action from every agent lands in one structured audit stream you can filter by agent, action type, or time window when something needs explaining.

Explore Swfte Nexus

Common questions

What is the systemctl command to see service logs?: There is none: systemctl status shows only the last few journal lines as a courtesy. The real tool is journalctl -u <service>, with -f to follow, -n for history depth, and --since for time windows.
Why does journalctl show no logs from before the last reboot?: The journal is in volatile mode, stored on a tmpfs under /run/log/journal and wiped at boot. Create /var/log/journal (with Storage=auto) or set Storage=persistent in /etc/systemd/journald.conf, restart systemd-journald, and history will survive reboots from then on.
How do I see only errors from a service?: journalctl -u <service> -p err shows entries at priority err and worse (crit, alert, emerg); use -p warning to include warnings. This relies on the service logging with proper priorities: plain stdout text from an app arrives at the default info-ish priority.
How do I export journalctl output to a file?: Plain redirection works: journalctl -u api --since today > api.log. Use -o short-iso for sortable timestamps or -o json for structured processing, and --no-pager when scripting so output is not piped through less.
Is journalctl -f the same as tail -f /var/log/syslog?: Functionally similar but richer: the journal is structured and indexed, so you can follow one unit, one priority, or one boot instead of grepping a flat file. On many modern distributions the text syslog file barely exists and journald is the primary log store.