Follow Run journalctl with a time window and -o json, and you get one JSON object per line with every field the journal stored:
sudo journalctl --since "2026-10-19 00:00" --until "2026-10-20 00:00" -o json --no-pager > web-03_journal.jsonl
For a syslog-style text file instead, use -o short-iso. Without sudo, or membership in systemd-journal, adm or wheel, you see only your own user journal, not the system’s.
On most modern distros, the journal is where everything lands first: services, the kernel, sudo, cron, logins. On Debian 12 and later, Fedora and Arch, it’s often the only place, because rsyslog isn’t installed. Prime Core has {N} detection rules for Linux system logs, mapped to {M} MITRE ATT&CK techniques, among them cron persistence (T1053.003), malicious systemd services (T1543.002) and sudo abuse (T1548.003).
Before you start
Permissions. Same rules as for any system log: root, or the groups above. Our [Linux log permissions guide] has the details.
Does the journal survive reboots? If /var/log/journal doesn’t exist, logs live in memory under /run/log/journal and disappear on reboot. journalctl –list-boots shows how many boots you actually have. If it lists only the current one, older history is gone.
How much is there? journalctl –disk-usage tells you before you dump it all into a file. By default, a persistent journal can grow to 10% of its filesystem, capped at 4 GB. That’s far more than you want to upload in one piece.
Time zones. The journal stores timestamps in UTC, but journalctl prints local time unless you add –utc. JSON output carries the raw UTC microsecond timestamp (__REALTIME_TIMESTAMP) either way.
Step 1: Narrow it down
Pick the filters that match your question. They combine:
| Filter | What it does |
|---|---|
| –since / –until | Time window; accepts “2026-10-19 14:00”, yesterday or “2 hours ago” |
| -b, -b -1 | Current boot, previous boot |
| -u nginx -u ssh | One or more systemd units |
| -p warning | That priority and anything more severe |
| -k | Kernel messages only |
| _COMM=sudo, _UID=0 | Match any journal field exactly |
Step 2: Pick the output format
- -o json: one JSON object per line, with every field. This is the default choice for LogTotal, because nothing gets lost.
- -o json –output-fields=MESSAGE,_HOSTNAME,_COMM,_PID,SYSLOG_IDENTIFIER,PRIORITY: the same, trimmed. A few fields, such as the timestamps and the boot ID, are always included. This cuts file size dramatically.
- -o short-iso: syslog-style text with full ISO timestamps. Smaller and easy to read by eye. [PROOF: confirm LogTotal parses short-iso]
Don’t use -o export. Despite the name, it’s a serialization format for shipping journals between systemd machines, not something to analyze.
We recommend you a typical scoped export:
sudo journalctl -b -1 -p info -u ssh -u cron \
-o json --no-pager > web-03_prevboot.jsonl
Step 3 (optional): Read journal files from another machine
In incident work, you often have a disk image or a copied /var/log/journal folder rather than a live system. journalctl reads those directly:
journalctl -D /mnt/evidence/var/log/journal -o json --no-pager > evidence_journal.jsonl
Use –file to point at individual .journal files. A journal from a crashed or uncleanly shut down system may print corruption warnings. Most entries usually still come out.
Upload, sanitize and review in LogTotal
- Upload. Open logtotal.com and drop in the .jsonl file. [PROOF: upload screen, size limit]
- Sanitize. [PROOF: what gets masked in journal JSON: hostnames, usernames, IPs, machine and boot IDs]. Look it over before you continue.
- Review. [PROOF: what the results screen shows]
What this looks like on real data. We exported a day of journal from [PROOF: sample source, e.g. a throwaway test VM after adding a cron job, a new user and a suspicious systemd service]. LogTotal flagged [PROOF: actual findings]. [PROOF: link to the sample file]
When it goes wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| Hint about not seeing messages from other users | Not root, and not in the journal groups | sudo, or add the account to systemd-journal |
| — No entries — | Time window or unit name doesn’t match; local vs. UTC confusion | Widen the window; try –utc; check systemctl list-units |
| Only the current boot exists | Volatile journal | Older logs are gone; check your log forwarder or SIEM |
| Output looks binary or garbled | -o export was used | Use -o json |
| The file is gigabytes | No filters | Add units, priority, –output-fields |
FAQ
JSON or text?
JSON for analysis, because it keeps PID, unit, boot ID and exact timestamps as separate fields. Text when a person will read it, or when size matters.
Is the journal the same as /var/log/syslog?
No. When rsyslog is installed, it copies messages from the journal into text files, so you may have both. When it isn’t, the journal is all there is.
