WIUNIX ACADEMY
Investigate the previous Linux boot with journalctl
After an unexpected restart, find the right boot, narrow the timeline to a service or the kernel, and keep a small private evidence file.
Make this guide yoursYOUR SYSTEM. YOUR STEPS.
Where are you working?
Choose your OS and version. The prerequisites, commands and troubleshooting follow your environment.
THE OUTCOME
What will you have at the end?
After an unexpected restart, find the right boot, narrow the timeline to a service or the kernel, and keep a small private evidence file.
Supported operating systems and versions
Documentation-reviewed paths for Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Arch Linux and Manjaro. Requires a systemd host; Windows, macOS and non-systemd hosts do not have this journal.
Before you begin
- Authorized shell on the affected systemd host and a rough incident time. For system-wide entries, use an approved account with journal access or authorized sudo.
- Use a private working directory for any export. Logs can include account names, network addresses or secrets written by applications.
Start with the time the service disappeared
Keep the alert timestamp and its timezone. A service restart does not necessarily mean the whole machine rebooted. Start by finding a boot whose recorded window matches the incident; then compare the last messages from that boot with the first messages after startup.
An abrupt end to the journal is a clue, not a diagnosis. Power loss, a hard reset, a kernel failure and missing log writes can all leave gaps. Check hypervisor, power or monitoring records if the host journal cannot explain the event.
LET’S BUILD
Confirm the host uses systemd
An ordinary container or an offline rescue image can show its own PID 1 or a different journal. Check the release, PID 1 and journalctl before interpreting any boot list.
journalctl comes from systemd. Reading the journal does not require reinstalling systemd or switching init systems.
Authorized terminal on the affected host
cat /etc/os-release
rpm -q systemd
ps -p 1 -o comm=
journalctl --versionPID 1 is systemd on the host branch, and journalctl reports a version.
LET’S BUILD
Pick a boot by its recorded dates
List the available boots in UTC. Index 0 normally identifies the running boot and -1 the previous entry, but the list contains only boots still visible in the journal. Copy the full ID for the time you care about so a later reboot cannot shift your selection.
If you get a permissions warning or see fewer boots than expected, repeat with authorized sudo before concluding that journal files are missing.
Authorized terminal on the affected host
journalctl --list-boots --utc --no-pagerThe list gives available boot IDs and their first and last retained entry timestamps.
LET’S BUILD
Read the end of that boot, then narrow by time
In the same shell, replace the placeholder with your full boot ID and set the UTC range around the alert. Read the last 40 entries for context, then the selected interval. Leave priorities unfiltered on this pass; routine shutdown messages can be as useful as errors. If you needed sudo for the boot list, use justified sudo for each journalctl read below as well; keep the export file itself under your own account. To compare the start of the running boot, read its first entries with the separate panel below.
Authorized terminal on the affected host
boot_id=PASTE_FULL_BOOT_ID
start='2026-11-15 08:10:00 UTC'
end='2026-11-15 08:20:00 UTC'
journalctl -b "$boot_id" -n 40 --utc --no-pager -o short-iso-precise
journalctl -b "$boot_id" --since "$start" --until "$end" --utc --no-pager -o short-iso-preciseThe last retained messages and the selected interval are displayed with UTC timestamps. Empty interval output calls for checking the ID, dates and permissions.
LET’S BUILD
Check the start of the current boot
Read the first 35 printed lines of this boot; the first line may be a journal banner. If the host rebooted again, select the exact successor boot ID from the list instead of 0.
Authorized terminal on the affected host
journalctl -b 0 --utc --no-pager -o short-iso-precise | head -n 35Early retained entries help bracket the interruption; they are not always the earliest events the machine experienced.
LET’S BUILD
Compare service and kernel messages
Set the exact failed service unit. A unit filter shows its journal context, while the kernel filter shows events such as a device reset or an out-of-memory kill. Compare timestamps and the named process or device before attributing the outage. An empty unit view may mean the service logs elsewhere.
Authorized terminal on the affected host
unit=example.service
journalctl -b "$boot_id" -u "$unit" --since "$start" --until "$end" --utc --no-pager
journalctl -b "$boot_id" -k --since "$start" --until "$end" --utc --no-pagerThe two views share the same boot and time window, making timeline comparison possible without reading unrelated boots.