25

For example:

┌─[10:50:38/hypership/root/~]
└─╼ journalctl -b
No journal files were found.
-- No entries --

┌─[10:50:46/hypership/root/~]
└─╼ journalctl --verify
No journal files were found.

/var/log is full of files though, and this was working before. Seems like an Arch Linux update may have caused this.

Any idea what the problem may be? What more info can I provide?

Improve this question
7
  • 1
    journalctl -k shows dmesg (kernel messages), you can get the same output by simple running the command "dmesg". To check if journalctl is working for non-kernel messages just type journalctl -b, if that doesn't give any logs then paste the output of systemctl status systemd-journald* Commented Jun 7, 2016 at 21:54
  • 1
    art thou root?? Commented Jun 8, 2016 at 17:55
  • @HeshamAhmed Updated my output to show output from -b and --verify options. Commented Jun 8, 2016 at 17:57
  • @PeterTurner Yeah, I'm root. Commented Jun 8, 2016 at 17:57
  • 1
    You could also get this error message, if you query logs for a specific service, and just made a typo in the service name, as I just did. Commented Apr 19, 2019 at 16:21

1 Answer 1

Reset to default
32
  1. sudo -i if not already.
  2. Try running journalctl -b to see messages from the current boot.
  3. If you still get -- No entries --, run journalctl --verify.
  4. If you get No journal files were found, something is corrupted with the journal service itself. Run systemctl status systemd-journald*
  5. If the services are all "green" (active/running), something is borked with the log files in /var/log/journal/<hash>. Try running the following to recreate them:

systemctl restart systemd-journald.service

The previous command will restart journald with a new hash under /var/log/journal. Now if you run journalctl -b you should see messages about the service itself starting.

Unfortunately the files under /var/log/journal are not parseable so figuring out the initial problem may be difficult, but at least logs going forward will work again.

Improve this answer
3
  • 5
    after systemctl restart systemd-journald.service everything worked fine! Commented Apr 27, 2021 at 14:41
  • 1
    systemctl restart systemd-journald.service worked perfectly. I had a fresh droplet created on DO which ships with systemd 245 version (Ubuntu 18.04) but all journal entries were missing. Commented Mar 1, 2022 at 5:35
  • on journalctl --verify I got 1 failure, but magically after that it all started working just fine :) Commented Apr 5, 2022 at 11:11

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.