Journal corruption detected

Fix Journalctl Log Corruption in systemd

Linux & Unix Beginner 👁 11 views 📅 Jun 29, 2026

Your systemd journal logs got corrupted after a crash or power loss. This shows when journalctl fails to read old logs. The fix clears the bad files.

You're running journalctl on your Linux machine and instead of seeing your logs you get an error message like "Journal corruption detected" or "Corrupted journal file". This usually happens after a hard crash—power outage, kernel panic, or forced shutdown. I've seen it on Ubuntu 22.04 servers and Arch desktop machines after a freeze that required holding the power button. The journal files are stored on disk and if the system goes down while writing to them, those files break.

The root cause: systemd's journal daemon (systemd-journald) writes log entries to binary files on disk. Binary format is fast but not crash-proof. When the system gets yanked off, the file state doesn't get a clean flush. Next boot, journalctl tries to read those broken files and throws up a corruption error. Don't panic—it's a messy file, not your whole system.

Here's the fix. We'll remove the corrupt journal files. systemd-journald will create fresh ones automatically.

Step 1: Stop the journal service

You can't delete journal files while they're in use. First stop the service.

sudo systemctl stop systemd-journald

After running that, you should get no output—that's normal. To check it stopped, run sudo systemctl status systemd-journald. It will say "inactive (dead)".

Step 2: Find and delete corrupt journal files

Journal files live in /var/log/journal/. Inside there's a folder with a long hex name (the machine ID). We'll go there and remove all old journal files.

cd /var/log/journal
ls -la

You'll see one folder like 3e8b8c9f4a1b2d3c4e5f6a7b8c9d0e1f (your machine ID). Go into it.

cd 3e8b8c9f4a1b2d3c4e5f6a7b8c9d0e1f
ls -la

You'll see files named like system@123456.journal and user-1000.journal. These are the corrupt ones. Delete all journal files in that folder.

sudo rm -f *.journal

After this, run ls again. The folder should be empty. If you see any remaining files (like system.journal), delete them too.

Note: Some guides say to only delete files with specific sizes. I say delete everything. systemd-journald will rebuild them from scratch. No logs are lost except the ones already failing to read.

Step 3: Restart the journal service

Now start the daemon again. It will create new clean journal files.

sudo systemctl start systemd-journald

Check it's running.

sudo systemctl status systemd-journald

It should say "active (running)". Wait a few seconds for it to write initial logs.

Step 4: Test journalctl works

Run journalctl to see current logs.

journalctl -xe

This shows the latest entries. You should see current messages from boot without errors. If you still see "Journal corruption detected", try a reboot. Sometimes journald keeps old file handles open.

If it still fails

Two things to check. First, disk space. A full disk can prevent journald from writing new files. Run df -h /var/log. If it's 100% full, free up space—delete old package caches or log files.

Second, permissions. The journal folder must be owned by systemd-journal. Run:

sudo chown -R systemd-journal:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

This fixes ownership and sets the sticky group bit so new files inherit the correct group.

If you're still stuck after both, the disk itself might have bad sectors. Check with sudo smartctl -a /dev/sda (replace sda with your drive). But 9 times out of 10, deleting the corrupt journal files is all it takes.

Was this solution helpful?