How to View and Manage Systemd Logs with Journalctl

The systemd daemon uses a centralized logging system called a journal, which is managed by the journald daemon. This daemon collects all log entries generated by the Linux kernel or any other systemd unit service regardless of their origin and stores them in a format that is easy to access and manipulate. The journalctl utility is provided for querying and filtering the data held within the journal as written by the journald service,

While diagnosing or troubleshooting an issue with the server or one of our services, the first place to look is the log entries in the journal. Due to its centralized nature, the journal could potentially contain thousands of log entries that may not be relevant to our current problem. Therefore, it's necessary to filter out what we don't need to quickly find the relevant information that will help us solve the problem, and that's what this tutorial is all about.

Prerequisites

Before you proceed with this tutorial, you will need the following:

• A Linux server that includes a non-root user with sudo access. We tested all the commands presented in this guide on an Ubuntu 20.04 server.
• A basic understanding of how logging works in Linux.

Step 1 — Permitting a user to view the system logs

By default, a user can only see log entries from systemd services under the user's control. If you run the journalctl command without any arguments, you may see the following message at the top of the output:

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
. . .

This informs you that the output produced by the utility does not include entries created by system services and those under other users' control. The way to ensure that you can view all log messages is by adding the user to an existing group such as adm or systemd-journal.

Go ahead and add the current user to the systemd-journal group using the command below:

sudo usermod -a -G systemd-journal <user>

After logging out and logging back in again, you'll be able to to see all the available messages, and not just the ones that pertain to the current user.

Step 2 — Querying the journal with Journalctl

In this section, we will query the systemd journal using journalctl, and view the results in various ways. Enter the command below to see all the logs collected by the journald daemon:

journalctl

When used alone without any options, the journalctl command will output all the journal entries on the system and pipe them through a pager (usually less). You can also cause journalctl to print its output directly to the standard output instead of using a pager by including the --no-pager flag. This is useful if you want to process the data further with text processing tools like grep, awk, or sed, or redirect the output to a file.

journalctl --no-pager

The first line of the output is a header that describes the time range of the displayed logs:

-- Logs begin at Fri 2022-02-11 15:34:17 UTC, end at Wed 2022-02-16 08:57:01 UTC. --

Below the header, you will see log entries generated by various programs in the following format and sorted from oldest to newest:

Feb 16 08:59:57 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"devankoshal","facility":"ftp","hostname":"we.com","message":"Take a breath, let it go, walk away","msgid":"ID911","procid":1211,"severity":"debug","timestamp":"2022-0>
Feb 16 08:59:58 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"Karimmove","facility":"alert","hostname":"for.de","message":"Maybe we just shouldn't use computers","msgid":"ID528","procid":3542,"severity":"debug","timestamp":"2022>
Feb 16 08:59:59 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"jesseddy","facility":"authpriv","hostname":"some.net","message":"You're not gonna believe what just happened","msgid":"ID427","procid":7885,"severity":"alert","timest>
Feb 16 09:00:00 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"benefritz","facility":"daemon","hostname":"up.us","message":"We're gonna need a bigger boat","msgid":"ID220","procid":5116,"severity":"crit","timestamp":"2022-02-16T0>
Feb 16 09:00:01 ubuntu-2gb-nbg1-1 CRON[100444]: pam_unix(cron:session): session opened for user ayo by (uid=0)
Feb 16 09:00:01 ubuntu-2gb-nbg1-1 CRON[100445]: (ayo) CMD (/usr/sbin/logrotate /home/ayo/logrotate.conf --state /home/ayo/custom-state)
Feb 16 09:00:01 ubuntu-2gb-nbg1-1 CRON[100444]: pam_unix(cron:session): session closed for user ayo
Feb 16 09:00:01 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"benefritz","facility":"uucp","hostname":"make.de","message":"You're not gonna believe what just happened","msgid":"ID783","procid":6478,"severity":"debug","timestamp">
Feb 16 09:00:02 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"meln1ks","facility":"clockd","hostname":"for.net","message":"#hugops to everyone who has to deal with this","msgid":"ID114","procid":8519,"severity":"debug","timestam>
Feb 16 09:00:03 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"shaneIxD","facility":"cron","hostname":"make.org","message":"Maybe we just shouldn't use computers","msgid":"ID196","procid":2970,"severity":"err","timestamp":"2022-0>

Each entry starts with a timestamp, the hostname of the machine, the program that generated the log entry, and its process id. The log message itself comes afterward.

If you want to print only the last few log entries, you can use the -n option, which will restrict the printed entries to specified number:

journalctl -n 10 # print the last 10 entries

You can also view incoming log messages in real-time through the -f flag, which imitates tail -f:

journalctl -f

In later sections, we'll look at more sophisticated ways of filtering the logs produced by journalctl so that we can find the information we're looking for quickly. Let's discuss customizing the output of the journalctl command first though.

Step 3 — Customizing the log output format

When parsing the log entries produced by journalctl, it may be useful to change the format to an easy to parse format like JSON. This is possible by specifying the json format through the -o option:

journalctl -o json -n 10 --no-pager

This yields the following output:

{"_SELINUX_CONTEXT":"unconfined\n","SYSLOG_FACILITY":"3","_SYSTEMD_SLICE":"system.slice","MESSAGE":"{\"appname\":\"shaneIxD\",\"facility\":\"mail\",\"hostname\":\"make.com\",\"message\":\"A bug was encountered but not in Vector, which doesn't have bugs\",\"msgid\":\"ID598\",\"procid\":2005,\"severity\":\"crit\",\"timestamp\":\"2022-02-16T23:29:58.696Z\",\"version\":1}","_SYSTEMD_UNIT":"vector.service","_SYSTEMD_CGROUP":"/system.slice/vector.service","_HOSTNAME":"ubuntu-2gb-nbg1-1","SYSLOG_IDENTIFIER":"vector","_COMM":"vector","_SYSTEMD_INVOCATION_ID":"5435d275748449c58c051f7c6ecc2e8c","_PID":"74071","_MACHINE_ID":"cee31bed2e414d19ab394c074b55b354","_EXE":"/usr/bin/vector","__REALTIME_TIMESTAMP":"1645054198697037","_STREAM_ID":"a5e2ba59f2d34a829098f6f9db57be9c","_BOOT_ID":"06a58ed252614238b0d09d15161688ed","__MONOTONIC_TIMESTAMP":"481325512974","_TRANSPORT":"stdout","_GID":"997","_UID":"997","PRIORITY":"6","_CAP_EFFECTIVE":"400","_CMDLINE":"/usr/bin/vector","__CURSOR":"s=d96f9da5333a4e1d8394272215ea1917;i=2d710c;b=06a58ed252614238b0d09d15161688ed;m=70113c790e;t=5d82b07264c4d;x=bb9760a144a3a0d1"}
. . .

Notice how detailed this output is compared to the default and how more information is contained therein. You can also specify json-pretty instead of json:

journalctl -o json-pretty -n 10 --no-pager

This makes the command output more readable at the cost of screen real-estate:

{
        "_PID" : "74071",
        "_SYSTEMD_INVOCATION_ID" : "5435d275748449c58c051f7c6ecc2e8c",
        "_MACHINE_ID" : "cee31bed2e414d19ab394c074b55b354",
        "_SELINUX_CONTEXT" : "unconfined\n",
        "PRIORITY" : "6",
        "__MONOTONIC_TIMESTAMP" : "481505512370",
        "_HOSTNAME" : "ubuntu-2gb-nbg1-1",
        "_SYSTEMD_SLICE" : "system.slice",
        "SYSLOG_FACILITY" : "3",
        "MESSAGE" : "{\"appname\":\"benefritz\",\"facility\":\"lpr\",\"hostname\":\"we.com\",\"message\":\"There's a breach in the warp core, captain\",\"msgid\":\"ID448\",\"procid\":8376,\"severity\":\"crit\",\"timestamp\":\"2022-02-16T23:32:58.695Z\",\"version\":2}",
        "SYSLOG_IDENTIFIER" : "vector",
        "_SYSTEMD_CGROUP" : "/system.slice/vector.service",
        "_UID" : "997",
        "_CAP_EFFECTIVE" : "400",
        "_STREAM_ID" : "a5e2ba59f2d34a829098f6f9db57be9c",
        "_SYSTEMD_UNIT" : "vector.service",
        "__CURSOR" : "s=d96f9da5333a4e1d8394272215ea1917;i=2d71f5;b=06a58ed252614238b0d09d15161688ed;m=701bf70bb2;t=5d82b11e0def1;x=529c820dc1c2952c",
        "_GID" : "997",
        "__REALTIME_TIMESTAMP" : "1645054378696433",
        "_COMM" : "vector",
        "_EXE" : "/usr/bin/vector",
        "_TRANSPORT" : "stdout",
        "_CMDLINE" : "/usr/bin/vector",
        "_BOOT_ID" : "06a58ed252614238b0d09d15161688ed"
}

Here's a few of all available formats that control the output produced by journalctl. You can examine the complete list here.

• cat: includes the log message only.
• short: the default output format.
• json: JSON-formatted output containing all available journal fields.
• json-pretty: prettified JSON output for better readability.
• verbose: displays the full log entry with all fields.

Now that we have a handle on how to present the journalctl output in different ways, let's look at a few ways to narrow down the entries produced by the utility.

Step 4 — Filtering the journal by boot session

One of the most common ways to filter the journalctl output is by only including messages that were logged after a specific system boot. For example, you can view all the logs collected since the most recent boot by executing journalctl with -b flag:

journalctl -b

The program should display an output similar to the one shown below:

-- Logs begin at Fri 2022-02-11 15:34:17 UTC, end at Wed 2022-02-16 09:24:09 UTC. --
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Stopped target Main User Target.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Stopped target Basic System.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Stopped target Paths.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Stopped target Sockets.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Stopped target Timers.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: dbus.socket: Succeeded.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Closed D-Bus User Message Bus Socket.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: dirmngr.socket: Succeeded.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Closed GnuPG network certificate management daemon.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: gpg-agent-browser.socket: Succeeded.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: gpg-agent-extra.socket: Succeeded.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: gpg-agent-ssh.socket: Succeeded.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: gpg-agent.socket: Succeeded.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: Closed GnuPG cryptographic agent and passphrase cache.
Feb 11 15:34:17 ubuntu-2gb-nbg1-1 systemd[1279]: pk-debconf-helper.socket: Succeeded.

. . .

This output shows all records in chronological order as before. Before seeing application logs, you will observe that the oldest records show very low-level kernel information about the system boot processes.

If you want to print the logs that pertain to a boot session other than the last one, you can list all boots that journald knows about by executing journalctl with parameter --list-boots:

journalctl --list-boots

You'll see the program's output appear on the screen:

-3 9a8ebc63800e4b488b8b0fe90991600c Thu 2021-03-25 18:44:20 UTC—Thu 2021-03-25 18:57:41 UTC
-2 8a0a7c2d722d49f3ba3f411cf2344bb8 Thu 2021-03-25 18:58:11 UTC—Wed 2021-04-14 16:00:31 UTC
-1 0f419686d8744067acd4e7ab962a280b Wed 2021-04-14 16:01:14 UTC—Thu 2021-04-15 14:02:09 UTC
 0 dbf7a43ac05f45e39be23091acf434bc Thu 2021-04-15 14:02:32 UTC—Thu 2021-04-15 18:00:31 UTC

The output shows all the available system boots with their offset number, boot ID (an hexadecimal number), and time range. The value from the offset column can be used as shown below:

journalctl -b 0 # same as journalctl -b
$ journalctl -b -1 # output logs from the previous boot session

You can also use the boot ID as shown below:

journalctl -b 0f419686d8744067acd4e7ab962a280b

This will show all the log entries that were collected within the boot session from 2021-04-14 16:01:14 to 2021-04-15 14:02:09.

When dealing with servers that do not often reboot, filtering the logs by system boot may not be helpful as the current boot session may be the only one available. Therefore, in the next section, we'll consider a more granular way to restrict the log entries outputted by journalctl.

Step 5 — Showing logs within a time range

A typical way to filter system logs is by querying for those that fall before, after, or between a given period. You can use the --since flag to specify a lower time limit and the --until for an upper limit. Both flags accepts a timestamp value that follows the systemd.time specification. The following are examples of valid arguments to --since and -until.

• 2021-11-23 23:02:15
• 2021-05-04
• 12:00
• 5 hour ago, or 32 min ago
• yesterday, today, now

Let's go ahead and view today's records using the command below:

journalctl --since 'today'

You'll see the program's output appear on the screen:

-- Logs begin at Fri 2022-02-11 15:34:17 UTC, end at Wed 2022-02-16 21:33:52 UTC. --
Feb 16 00:00:00 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"ahmadajmi","facility":"local4","hostname":"we.com","message":"#hugops to everyone who has to deal with this","msgid":"ID844","procid":113,"severity":"alert","timestam>
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 systemd[1]: Starting Rotate log files...
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 systemd[1]: Starting Daily man-db regeneration...
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 CRON[79633]: pam_unix(cron:session): session opened for user ayo by (uid=0)
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 CRON[79641]: (ayo) CMD (/usr/sbin/logrotate /home/ayo/logrotate.conf --state /home/ayo/custom-state)
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 CRON[79633]: pam_unix(cron:session): session closed for user ayo
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 systemd[1]: logrotate.service: Succeeded.
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 systemd[1]: Finished Rotate log files.
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"meln1ks","facility":"ntp","hostname":"make.net","message":"You're not gonna believe what just happened","msgid":"ID477","procid":6062,"severity":"notice","timestamp":>
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 systemd[1]: man-db.service: Succeeded.
Feb 16 00:00:01 ubuntu-2gb-nbg1-1 systemd[1]: Finished Daily man-db regeneration.
Feb 16 00:00:02 ubuntu-2gb-nbg1-1 vector[74071]: {"appname":"shaneIxD","facility":"daemon","hostname":"names.com","message":"Take a breath, let it go, walk away","msgid":"ID74","procid":1031,"severity":"notice","timestamp":"202>

The output may show a lot of records, but you'll observe that they were all recorded on the current day. You can also filter logs that fall on a specific date or between specific dates:

journalctl --since '2022-02-16 21:00:00' --until '2022-02-16 22:00:00'

As you can see, journalctl provides great flexibility when it comes to filtering records by time. However, the log entries still contain records from several different services. If you're only interested in a records from a specific application, filtering by time only will still yield irrelevant messages. In the next section, we'll consider how to restrict the journalctl output to entries produced by a specific systemd service.

Step 6 — Filtering journal entries by service

If you are interested only in log entries related to a specific systemd unit service, you can pass the service name to the -u flag. For example, let's view the last 10 log messages produced by the sshd service using the command shown below:

journalctl -u sshd.service -n 10

You'll see the program's output appear on the screen:

-- Logs begin at Fri 2022-02-11 15:34:17 UTC, end at Wed 2022-02-16 22:03:52 UTC. --
Feb 16 21:56:48 ubuntu-2gb-nbg1-1 sshd[61254]: Received disconnect from 122.194.229.45 port 19218:11:  [preauth]
Feb 16 21:56:48 ubuntu-2gb-nbg1-1 sshd[61254]: Disconnected from 122.194.229.45 port 19218 [preauth]
Feb 16 21:57:39 ubuntu-2gb-nbg1-1 sshd[61258]: Invalid user test3 from 45.112.242.67 port 55536
Feb 16 21:57:39 ubuntu-2gb-nbg1-1 sshd[61258]: Received disconnect from 45.112.242.67 port 55536:11: Bye Bye [preauth]
Feb 16 21:57:39 ubuntu-2gb-nbg1-1 sshd[61258]: Disconnected from invalid user test3 45.112.242.67 port 55536 [preauth]
Feb 16 21:57:52 ubuntu-2gb-nbg1-1 sshd[61260]: Invalid user wedding from 51.140.185.84 port 51118
Feb 16 21:57:52 ubuntu-2gb-nbg1-1 sshd[61260]: Received disconnect from 51.140.185.84 port 51118:11: Bye Bye [preauth]
Feb 16 21:57:52 ubuntu-2gb-nbg1-1 sshd[61260]: Disconnected from invalid user wedding 51.140.185.84 port 51118 [preauth]
Feb 16 21:59:41 ubuntu-2gb-nbg1-1 sshd[61265]: Accepted publickey for ayo from 217.138.222.109 port 59800 ssh2: RSA SHA256:8Gdo7Q35uybWwTaGAoWrQXowqn0MEGaErerTlpR7nTM
Feb 16 21:59:41 ubuntu-2gb-nbg1-1 sshd[61265]: pam_unix(sshd:session): session opened for user ayo(uid=1000) by (uid=0)

From the output above, you can observe that only the records that pertain to sshd are displayed. If you need to view the logs for more than one service, you can repeat the -u flag in the command with the names of different services.

journalctl -u rsyslog.service -u nginx.service --since today

The entries produced from both services will be merged and presented in chronological order. You can also use the --since and --until flags to narrow down the results further as you see fit.

Step 7 — Filtering journal entries by priority level

Each journal record has a well-defined structure that also includes message priority. The journalctl command allows filtering records by message priority, which are the same as the standard syslog priority levels (listed in descending order):

{
  emerg: 0,
  alert: 1,
  crit: 2,
  error: 3,
  warning: 4,
  notice: 5,
  info: 6,
  debug: 7
}

Here's an explanation of the levels above:

• emerg: the system is unusable.
• alert: action must be taken immediately.
• crit: critical conditions.
• err: error conditions.
• warning: warning conditions.
• notice: normal, but significant condition.
• info: informational message.
• debug: messages that are useful for debugging.

You can specify the priority name or its corresponding number value when filtering log records with journalctl by using the -p option:

journalctl -p err
# or
$ journalctl -p 3

The command above will display all messages prioritized at err level or above. This means that the output will not contain messages logged at warning level or below.

-- Logs begin at Fri 2022-02-11 15:34:17 UTC, end at Wed 2022-02-16 22:58:21 UTC. --
Feb 11 15:41:23 ubuntu-2gb-nbg1-1 sudo[909]: pam_unix(sudo:auth): auth could not identify password for [ayo]
Feb 11 15:41:23 ubuntu-2gb-nbg1-1 sudo[909]:      ayo : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/ayo ; USER=root ; COMMAND=/usr/bin/dnf install fish
Feb 11 15:41:34 ubuntu-2gb-nbg1-1 sudo[911]:      ayo : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/ayo ; USER=root ; COMMAND=/usr/bin/dnf update
Feb 11 15:44:31 ubuntu-2gb-nbg1-1 sshd[976]: fatal: Timeout before authentication for 1.15.86.71 port 41058
Feb 11 20:38:11 ubuntu-2gb-nbg1-1 sshd[3300]: error: kex_exchange_identification: Connection closed by remote host
Feb 11 20:58:23 ubuntu-2gb-nbg1-1 sshd[3348]: error: kex_exchange_identification: Connection closed by remote host
Feb 12 00:44:08 ubuntu-2gb-nbg1-1 sshd[4536]: error: kex_exchange_identification: Connection closed by remote host
Feb 12 01:22:43 ubuntu-2gb-nbg1-1 sshd[4622]: error: kex_exchange_identification: Connection closed by remote host
. . .

This feature makes it easy to remove irrelevant information when troubleshooting a problem so that the higher priority messages can take center stage.

Step 8 — Cleaning up old journal entries

The journalctl command also provides control over how much space is used up by the journal, and when to clean up older entries. You can use the --disk-usage flag to discover how much is currently being used up:

journalctl --disk-usage

You should see the following output:

Archived and active journals take up 1.8G in the file system.

If you want to shrink your journal to a certain size, you can use the --vacuum-size option as shown below:

sudo journalctl --vacuum-size=500M # shrink journal to 500 MB.

You'll see the program's output appear on the screen:

Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-00000000001705f4-0005d7c8815c6001.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-000000000018a118-0005d7ccffbf428b.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-00000000001a39bc-0005d7d1621e9d0e.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-00000000001bd232-0005d7d5977c6dd9.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-00000000001d6237-0005d7d9614516c8.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-00000000001ef1f4-0005d7dd2e4431c9.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-00000000002081d7-0005d7e0f8261d1a.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-000000000022130a-0005d7e4c5032aa2.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-000000000023ac43-0005d7e9129c10c1.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-000000000025457d-0005d7ecc6945d7e.journal (128.0M).
Deleted archived journal /var/log/journal/cee31bed2e414d19ab394c074b55b354/system@d96f9da5333a4e1d8394272215ea1917-000000000026d5ce-0005d7f0c66f8cfe.journal (128.0M).
Vacuuming done, freed 1.3G of archived journals from /var/log/journal/cee31bed2e414d19ab394c074b55b354.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal.

As you can see, the journal was shrunk to 500 MB after log entries totalling 1.3 GB in size were deleted from the archive. An alternative to --vacuum-size is the --vacuum-time option which allows you to delete logs older than a certain period of time.

For example, you can delete the entries that were created more than one month ago through the command below:

sudo journalctl --vacuum-time=1month

You can also limit the storage space that the journal takes up by editing the following options in the /etc/systemd/journald.conf file:

• SystemMaxUse= and RuntimeMaxUse=: the maximum amount of space that the journal should take up in a persistent storage (/var/log/journal) and in-memory storage (/run/log/journal) respectively.
• SystemKeepFree= and RuntimeKeepFree=: defines the percentage of disk space that should be kept free for other uses.
• SystemMaxFileSize= and RuntimeMaxFileSize=: controls how large journal entries should grow before being rotated.
• SystemMaxFiles= and RuntimeMaxFiles=: controls the maximum number of journal files to keep.

Conclusion

In this article, you learned about the systemd journal and how to manage it through the journalctl command. We started by discussing what the journal is for, and then described how to view and filter its entries in various ways. To learn more about the systemd journal and the journalctl command, consult the official documentation or type man journalctl in your terminal.

Thanks for reading, and happy logging!

Article by

Ayooluwa Isaiah

Ayo is the Head of Content at Better Stack. His passion is simplifying and communicating complex technical ideas effectively. His work was featured on several esteemed publications including LWN.net, Digital Ocean, and CSS-Tricks. When he’s not writing or coding, he loves to travel, bike, and play tennis.

Got an article suggestion? Let us know

Next article

How to View and Configure Apache Access & Error Logs

Learn how to view and configure Apache access and error logs.

→

Explore more

Learn everything you want to know about logging. Go from basics to best practices in no time.

linux journald

Administering System Logs on Linux

Learn how to view and configure linux system logs on ubuntu 20.04

Rotating Logs with Logrotate

Learn how to use the Logrotate utility to set up automatic rotation, compression and deletion of log files in Linux

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.