How to Use Journalctl to Read Linux System Logs

For many years system and kernel logs were handled by a utility called syslogd. Most Linux-based operating systems have migrated to systemd, which comes with a different log daemon, journald. To interact with these logs, you use the journalctl utility.

Give User Permission to Read System Logs

Only users belonging to the “adm” or “systemd-journal” groups can read systemd logs. Distributions such as Ubuntu already add you as a user to the adm group.

Open a terminal emulator and type the following command:


If you see “adm” or “systemd-journal” in the output, you can skip the rest of the steps in this section. Otherwise, add yourself to the “adm” group.

You would have to restart your login session for this change to take effect (log out and log in). If you can’t do that for various reasons, use this command to log in to the new group without restarting the graphical session.

Don’t close the terminal window. You are now part of the adm group – in the terminal session, but not in your graphical session. If you open a new terminal at this time, your user won’t be logged in to the adm group anymore.

Check If Journal Is Persistent

The systemd logs can be persistent or volatile. On Ubuntu and other distros, they are persistent by default. On Debian 9 they are volatile, meaning they’re kept only in memory (not disk) and disappear at shutdown or reboot. Enter the following command.


If there are multiple entries here, there’s nothing more you have to do. It means journals are kept on disk (persistent). If you only get one entry, then the journal is volatile. Change it to persistent.

Select Which Boot Entry Journal to View

Usually, you will want to see the log for the current boot. On rare occasions you will want to see the previous boot, when something went wrong, for example, after a system crash.

To view the log for the current boot:


For the previous boot, use “-1” instead of “0,” and for two boots ago, “-2” and so on.

Navigate and Search Through the System Journal

After you open the log with journalctl, you can navigate through the text with arrow keys and PAGE UP or PAGE DOWN keys. Other useful keys are:

  • > to go to the end of the output.
  • < to go to the beginning of the output.
  • / to search for a string of text. After you press the slash key, enter the string you want to find, followed by Enter. The string is case sensitive, so “network” won’t find “Network” strings. The search begins from your current view position, downwards. To search upwards, use ?.
  • n find the next match in a current search. N finds the previous.
  • q quits the journalctl utility.


Filter Log Entries by Priority

Sometimes you only want to search for errors, ignoring notices and status messages. Each entry in a log has a priority: emergency, alert, critical, error, warning, notice, info. These are listed in order of importance, emergency being reserved for worst case scenarios (system unusable). Info messages are just informational text, reporting status of programs that work normally.

To only display error messages from the current boot, enter:


If you want to see errors from all boots, just remove the “-b” parameter:

These are the codes you can pass to the “-p” parameter:

  • alert
  • crit
  • debug
  • emerg
  • err
  • info
  • notice
  • warning

Filter Log Entries by Path to Process Executable File or Systemd Unit

Some processes are started and managed by so-called systemd units. To see all logs related to the cron service unit, enter:

You can see what units you have available with:


You can navigate the list with the up and down arrow keys. Press q to quit.

If you would rather use the path to the program’s executable file (binary), simply pass its full path as an argument.

Don’t forget, you can also filter by current boot entry to get rid of unnecessary messages.


Journalctl aims to make it easy to find what you’re looking for. If you want to learn about more advanced parameters you can use, consult the journalctl command manual page.

Alexandru Andrei

Fell in love with computers when he was four years old. 27 years later, the passion is still burning, fueling constant learning. Spends most of his time in terminal windows and SSH sessions, managing Linux desktops and servers.


  1. Nice. Thanks. I’ve looked at the journalctl output a few times and my lack of patience caused me to just dismiss it as too cumbersome to bother. That same lack of patience kept me from RTFM, and ultimately because I was able to resolve the challenge of the moment without leveraging journalctl. All that said, your article boiled it down nicely, and I can see how it will be a useful tool going forward, thanks.

    1. Thank you. I appreciate the feedback and I’m happy that I could help. I’ve tried to cherry pick the most important features or most often used. Otherwise, covering everything that journalctl can do, would require a tutorial at least ten times larger than this that (almost) nobody would want to read :D

Comments are closed.