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.

Conclusion

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.

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.

• Facebook
• Tweet

2 comments

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.

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 😀

Comments are closed.

Affiliate Disclosure: Make Tech Easier may earn commission on products purchased through our links, which supports the work we do for our readers.

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.

Conclusion

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.

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.

• Facebook
• Tweet

2 comments

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.

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 😀

Comments are closed.

Affiliate Disclosure: Make Tech Easier may earn commission on products purchased through our links, which supports the work we do for our readers.

journalctl command in Linux is used to view systemd, kernal and journal logs. The logs are presented in the following way:

It displays the paginated output, hence it is a bit easy to navigate through a lot of logs. It prints the log in the chronological order with the oldest first.

Working with journalctl command

1. To display all logs

It displays all the logs in the paginated view.

2. To reverse the order or to display the new entries first.

This will display the logs in the chronological order with the newest first.

3. To display only a few log entries

This will display just 2 log entries.

4. To get log entries containing a specific keyword.

This will display all the entries containing the word Centaur in them.

5. To display priority specific log entries.

It displays all log entries with priority as a warning.

6. To print verbose customized output.

This will display the formatted output in verbose mode.

7. To display the boots of the system.

To display all the boots of the system.

8. To display journalctl help.

The above command will display the help section of the journalctl command.

Despite some of the negative publicity, systemd have brought great new functionality to the Linux operating system. Logging is one of them. In the old days before systemd, checking logs and troubleshooting issues was sometimes very unpleasant thing to do because logs for different programs were scattered in different files and you had to check timestamps in each and every one of them. Of course there was syslog file also, but sometimes was not as verbose as needed. The systemd brings us journal daemon called journald which enables centralized management of logs. This logs can be filtered and manipulated by utility called journalctl. In this article we will go through basic usage of utilities.

What is journald

The journald is service that collects and stores logs from many sources, and make indexed structured log files that are easy to interpret. Some of the sources that journald uses

• Kernel log messages, via kmsg
• Simple system log messages, via the libc syslog call
• Structured system log messages via the native Journal API
• Standard output and standard error of system services

Idea is to have all log messages centralized, no matter from which application they are coming from.

Setting the time

In order for logs to be useful, you must have correct system time. Logs can have time by UTC or by local time. Generally both time-stamps are saved. So lets set up timezone first

This command sets the time to Central European timezone, but if you are on any other spot of the globe, you just need to enter continent and press tab to see cities you might chose. It doesn’t matter if it is not your city, I am not living in Belgrade either, it is just closest big city. Next lets see the status of the timezone

1) Viewing logs

Now that we have correct time, lets continue to viewing logs. The basic command for viewing logs is

It will get you output similar to this:

That is first line, and followed by many lines. We see that logs begin from last system boot. I last time rebooted the computer yesterday. By default, journald doesn’t save logs across reboots, because that would make log files get to big over time. The log seems similar to syslog, but it has many more sources. We said that both UTC and your local timezone timestamps are saved, so you can also look at the same logs with UTC timestamps.

Yes, I know that logs are huge. We said that logs will be great again! But they are too great, so the journald has neat feature of filtering logs.

If you want to see logs from some point in time till now, you need to use command formatted like this:

2) Filtering logs by time

This is still too big, so we can make them smaller if we add one more operand after –since, and that will be –until

In those five minutes, there were only two log massages.

Since and until flags accept the time stamps in format YYYY-MM-DD HH:MM:SS but that is not only way. If for example get a user complain that your server is not working in last 5 minutes, you can examine logs like this:

It also understands words like yesterday or today so you can look for logs since yesterday or today.

3) Setting up logging across reboots

This this all is more useful if you have the logs persistent across reboots. If you want logs to remain after boots, you need to enable this manually. First create directory where it is going to be logged

Then edit the configuration file to log persistently.

After this you can reboot your machine and check if boots span across reboots with following command:

I rebooted the computer two times and both boots are logged. I thought that previous boot would get saved as well but it did not. So only those reboots that are done after setting persistent logs will be logged.

4) Managing logs from different boots

If you now want to see logs from this boot only, you use command

You can use boot number to pick specific boot

Or you could use boot id

The time based filtering will also work

5) Filtering by service and id

Say you want to see logs by one program only. I will look logs of fprintd

You can also filter logs by UID. First you need to get UID of your user

And next you can use that uid to filter logs

You can also filter by GID

Now can filter by any of those GIDs

Filtering logs by path to to executable:

Seeing logs in real time

If you want your logs to be displayed in plan text for easy copy and paste, you can use “no pager” option

6) Displaying kernel messages and deleting old logs

The journalctl can display kernel messages as well. By default, it will display from current boot

If you want kernel messages from previous boot, you use the -b -1 flag.

To check how much disk space your logs use, you can use this command

If your logs have grown in size, you can use vacuum cleaner to wipe the oldest one. Well not really a vacuum cleaner, but command is called vacuum.

This will reduce the log size to 16MB.

Conclusion

We have gone through basic journald commands that make logging great again. This will hopefully help you greatly when you next time have to troubleshoot some sticky problem with your Linux server or desktop computer with systemd. The systemd is brings us great tools and negative publicity that it got early was just backlash against changing old tools that people were used too. I already got used to systemd and I don’t know how I lived without it. This is all for this article, thank you for reading and have a nice day.

TL;DR : run journalctl -f

-f is short option for –follow. You can think of running journalctl -f as doing a tail operation on the system log.

journalctl cheatsheet

-a or –all

Show all characters, even long and unprintable lines and characters

-f or –follow

Like a tail operation for viewing live updates

-e or –page-end

Jump to the end of the log

-n or –lines=

Show the most recent n number of log lines

-o or –output=

Customizable output formatting. See man page for formatting options. Some examples include journalctl -o verbose to show all fields, journalctl -o cat to show compact terse output, journalctl -o json for JSON formatted output.

-x or –catalog

Explain the output fields based on metadata in the program

-q or –quiet

suppress warnings or info messages

-m or –merge

merge based on time local and remote entries

–list-boots

Print out the bootids which can be later used in filtering from time of a specific bootid

-b [ID][±offset]

Filter only based on the specified boot

-k or –dmesg

Filter only kernel messages

-g or –grep

Filter based on perl-compatible regular expressions for specific text

–case-sensitive[=BOOLEAN]

do case insensitive searching

-S, –since=, -U, –until=

Search based on a date. “2019-07-04 13:19:17”, “00:00:00”, “yesterday”, “today”, “tomorrow”, “now” are valid formats. For complete time and date specification, see systemd.time(7)

–system

Show system messages only

Show user messages only

–disk-usage

Shows space used by this log system

The journalctl system takes system logging to the next level. To see all the options be sure to read the man page. I hope this cheat sheet helps you get started with some quick options.

About the author

Linux Wolfman

Linux Wolfman is interested in Operating Systems, File Systems, Databases and Analytics and always watching for new technologies and trends. Reach me by tweeting to @linuxhint and ask for the Wolfman.

Brittany Day

There are various commands available to Linux users for troubleshooting desktop and server logs. Learn the basics of the journalctl utility of Systemd and its commands that can be used to view and analyze Systemd Logs in this DebugPoint.com guide.

Many say that Systemd is not good, it is heavy on the system and it is a debated topic always. But you can not deny that it provides a well set of utilities to manage, troubleshoot a system. Imagine you end up with a broken system with no GUI. You probably messed up boot and GRUB as well. In those kinds of scenarios or in general – you can boot from a LIVE system, mount your Linux partition and explore the Systemd logs to find out about the problem.

Systemd has three basic components as follows –

• systemd: System and service manager for Linux operating systems.
• systemctl: Command to introspect and control the state of the systemd system and service manager.
• systemd-analyze: Provides system boot-up performance statistics and retrieve other state and tracing information from the system and service manager

Apart from these three, there are additional services that systemd provides such as – journald, logind, networkd, etc. In this guide we will talk about the journald service of systemd.

Systemd is a cutting-edge system and service manager for Linux systems: an init daemon replacement intended to start processes in parallel at system boot. It is now supported in a number of current mainstream distribution including Fedora, Debian, Ubuntu, OpenSuSE, Arch, RHEL, CentOS, etc.

Earlier on, we explained the story behind ‘init’ and ‘systemd’; where we discussed what the two daemons are, why ‘init’ technically needed to be replaced with ‘systemd’ as well as the main features of systemd.

One of the main advantages of systemd over other common init systems is, support for centralized management of system and processes logging using a journal. In this article, we will learn how to manage and view log messages under systemd using journalctl command in Linux.

Important: Before moving further in this guide, you may want to learn how to manage ‘Systemd’ services and units using ‘Systemctl’ command, and also create and run new service units in systemd using shell scripts in Linux. However, if you are okay with all the above, continue reading through.

Configuring Journald for Collecting Log Messages Under Systemd

journald is a daemon which gathers and writes journal entries from the entire system; these are essentially boot messages, messages from kernel and from syslog or various applications and it stores all the messages in a central location – journal file.

You can control the behavior of journald via its default configuration file: /etc/systemd/journald.conf which is generated at compile time. This file contains options whose values you may change to suite your local environment requirements.

Below is a sample of what the file looks like, viewed using the cat command.

Note that various package installs and use configuration extracts in /usr/lib/systemd/*.conf.d/ and run time configurations can be found in /run/systemd/journald.conf.d/*.conf which you may not necessarily use.

Enable Journal Data Storage On Disk

A number of Linux distributions including Ubuntu and it’s derivatives like Linux Mint do not enable persistent storage of boot messages on disk by default.

It is possible to enable this by setting the “Storage” option to “persistent” as shown below. This will create the /var/log/journal directory and all journal files will be stored under it.

For additional settings, find the meaning of all options which are supposed to be configured under the “[Journal]” section by typing.

Setting Correct System Time Using Timedatectl Command

For reliable log management under systemd using journald service, ensure that the time settings including the timezone is correct on the system.

In order to view the current date and time settings on your system, type.

To set the correct timezone and possibly system time, use the commands below.

Viewing Log Messages Using Journalctl Command

journalctl is a utility used to view the contents of the systemd journal (which is written by journald service).

To show all collected logs without any filtering, type.

View Log messages Based On Boots

You can display a list of boot numbers (relative to the current boot), their IDs, and the timestamps of the first and last message corresponding to the boot with the –list-boots option.

To view the journal entries from the current boot (number 0), use the -b switch like this (same as the sample output above).

and to see a journal from the previous boot, use the -1 relative pointer with the -b option as below.

Alternatively, use the boot ID like this.

Filtering Log Messages Based On Time

To use time in Coordinated Universal Time (UTC) format, add the –utc options as follows.

To see all of the entries since a particular date and time, e.g. June 15th, 2017 at 8:15 AM, type this command.

Viewing Recent Log Messages

To view recent log messages (10 by default), use the -n flag as shown below.

Viewing Log Messages Generated By Kernel

To see only kernel messages, similar to the dmesg command output, you can use the -k flag.

Viewing Log Messages Generated By Units

To can view all journal entries for a particular unit, use the -u switch as follows.

To zero down to the current boot, type this command.

To show logs from the previous boot, use this.

Below are some other useful commands:

Viewing Log Messages Generated By Processes

To view logs generated by a specific process, specify it’s PID like this.

Viewing Log Messages Generated By User or Group ID

To view logs generated by a specific user or group, specify it’s user or group ID like this.

Viewing Logs Generated By a File

To show all logs generated by a file (possibly an executable), such as the D-Bus executable or bash executables, simply type.

Viewing Log Messages By Priority

You can also filter output based on message priorities or priority ranges using the -p flag. The possible values are: 0 – emerg, 1 – alert, 2 – crit, 3 – err, 4 – warning, 5 – notice, 6 – info, 7 – debug):

To specify a range, use the format below (emerg to warning).

View Log Messages in Real-Time

You can practically watch logs as they are being written with the -f option (similar to tail -f functionality).

Handling Journal Display Formatting

If you want to control the output formatting of the journal entries, add the -o flag and use these options: cat, export, json, json-pretty, json-sse, short, short-iso, short-monotonic, short-precise and verbose(check meaning of options in the man page:

The cat option shows the actual message of each journal entry without any metadata (timestamp and so on).

Managing Journals On a System

To check the journal file for internal consistency, use the –verify option. If all is well, the output should indicate a PASS.

Deleting Old Journal Files

You can also display the current disk usage of all journal files with the –disk-usage options. It shows the sum of the disk usage of all archived and active journal files:

To delete old (archived) journal files run the commands below:

Rotating Journal Files

Last but not least, you can instruct journald to rotate journal files with the –rotate option. Note that this directive does not return until the rotation operation is finished:

For an in-depth usage guide and options, view the journalctl man page as follows.

Do check out some useful articles.

That’s it for now. Use the feedback from below to ask any questions or add you thoughts on this topic.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

In the past SystemV used syslog (or rsyslog) to log events to a log file. Many times there is a separate log file for each service.

With the switch to SystemD, Red Hat, Fedora, CentOS, etc. also introduced a new logging facility and tool called the journal. This centralized the collection of logs and allowed administrators one simple robust tool and one location to inspect and manipulate log data. Here we will cover some of the basics of journalctl, the program used to interface with the logs.

To simply view the logs on your system, you can execute the following command:

This will display the logs with the oldest entries first. Although this is simple, it is not very useful since we do not tend to read logs like a book.

By default journalctl displays the logs in a pager. It shows you one page of logs requiring you to hit the space bar to proceed. Also long log lines WILL NOT wrap, they will trail off the right side of the screen. You can use the right arrow to see the rest of the line.

We will talk more about changing the way the logs are displayed in a different article. Let’s move on to some basic log viewing commands.

Diplaying Logs by Date

More than likely you are looking for an event. One way to find something is the logs is to display the logs from a certain time. You can specify a single time and it will display all logs SINCE that time, or you can specify a time window.

To find all logs since December 25th 2015 at 07:00 PM you can run:

journalctl –since “2015-12-25 19:00:00”

To find all logs between December 25th 2015 and January 1st 2016:

journalctl –since “2015-12-25” –until “2016-1-1”

You can also use the more human friendly relative terms. For example, to see all logs since yesterday:

journalctl –since yesterday

You also have the option to mix the absolute and relative terms:

journalctl –since “2015-12-25” –until “2 hours ago”

Displaying Logs by Unit or Service

Another way to find the logs you need would be to filter the results by unit (or service). For example, if you want to see all the logs vsftpd (FTP software) produced you can specify that in the journalctl command like so:

journalctl -u vsftpd.service

You can mix in a time, or a time window to find logs from a specific service during a specific time.

To find all the vsftpd logs from December 5 2015 to January 8 2016 you can runt he following command:

journalctl -u vsftpd.service –since “2015-12-05 16:17:47” –until “2016-1-8 15:03:02”

You can also request logs from two different services at the same time. This comes in handy when trying to get information about how two services are interacting or debugging an issue.

To see all the logs from vsftpd and firewalld you can run this command:

journalctl -u vsftpd.service -u firewalld.service

You can also specify a time in absolute, relative or any combination.

journalctl -u vsftpd.service -u firewalld.service –since “2 days ago”
Displaying Logs by User or Group

Other things you can do is find logs generated by a specific user (UID) or group (GUID).

For example, let’s say I wanted to see all logs from the user “savona”. First I would find their UID like so:

]# id savona
uid=1000(savona) gid=1000(savona) groups=1000(savona)

Now that I know their UID is 1000, I can use the _UID filter in journalctl like so:

journalctl _UID=1000

And of course I can mix this with a time window:

journalctl _UID=1000 –since “2 days ago”

Displaying Logs by Process ID

You can also use _PID to search for process id, or _GUID for group id.

journalctl _PID=1221

Displaying Kernel Logs

Since all the logs are kept in one place, we can use the same tool (journalctl) to view just the kernel logs:

journalctl -k

The above command will show you all the kernel messages from the current boot. You can specify a different boot using the boot selection option like so:

journalctl -k -b 2

The above command will show you all the kernel messages from 2 boots ago.

Displaying Logs Since Last Boot

The boot selection option will work on it’s own as well. If you would like to see all the logs generated since the last boot up, simply give the -b option:

journalctl -b

Displaying Logs by Priority

You can also select to view logs by priority. The journal uses the same syslog message levels:

0: emerg
1: alert
2: critical
3: error
4: warning
5: notice
6: info
7: debug

To see all logs from priority 4 (warning) and higher:

journalctl -p 4

To see all the logs from priority 3 (error) and higher since last boot:

journalctl -p 3 -b

And of course you can use time windows if you like:

journalctl -p 3 –since “2 days ago”

Tailing or Following the Log

In my opinion on for the most useful commands for viewing logs, follow allows you to view the log as they are bring written. You may of used “tail -f” in the past. The journalctl utility has the same function.

journalctl -f

Also, similar to tail, you can view the last 10 entries by using the -n option like so:

journalctl -n

Or you can see the last 50 entries by specifying a number of the “-n” option:

journalctl -n 50

You can also see the last 50 entries, then begin to follow by mixing the commands like so:

journalctl -n 50 -f

Finding Size of Logs / Log Maintenance

To find how much disk space is being used by the journal simply ask:

journalctl –disk-usage

If you are concerned about disk space, you can trim (remove oldest) the logs.

You can do this by specifying the amount of disk space you want to keep or the time you would like to keep.

For example, if you want to delete all logs and keep just 5GB of data:

journalctl –vacuum-size=5GB

If you want to keep only logs from the last year:

journalctl –vacuum-time=1years

Now you should have a decent idea of how to find the logs you are looking for (I just said that in the voice of Obi-Wan). If you have any questions or require further explanation, please feel free to sound off in the comments.

I check service status with systemctl status service-name .

By default, I see few rows only, so I add -n50 to see more.

Sometimes, I want to see full log, from start. It could have 1000s of rows.
Now, I check it with -n10000 but that doesn’t look like neat solution.

Is there an option to check full systemd service log similar to less command?

5 Answers 5

Just use the journalctl command, as in:

Or, to see only log messages for the current boot:

For things named .service , you can actually just use , as in:

But for other sorts of units (sockets, targets, timers, etc), you need to be explicit.

In the above commands, the -u flag is short for –unit , and specifies the name of the unit in which you’re interested. -b is short for –boot , and restricts the output to only the current boot so that you don’t see lots of older messages. See the journalctl man page for more information.

systemctl can include the complete output of its status listing, without truncation., by adding the -l flag:

-l : don’t truncate entries with ellipses (. )

–no-pager can be added to avoid invoking a pager when the output is an interactive terminal.

Use journalctl to View Your System’s Logs

View journalctl without PagingPermalink To send your logs to standard output and avoid paging them, use the –no-pager option:

It’s not recommended that you do this without first filtering down the number of logs shown.

journalctl -u service-name.service

Show Logs within a Time RangePermalink Use the — since option to show logs after a specified date and time:

journalctl –since “2018-08-30 14:10:10”

Use the –until option to show logs up to a specified date and time:

journalctl –until “2018-09-02 12:05:50”

Combine these to show logs between the two times:

journalctl –since “2018-08-30 14:10:10” –until “2018-09-02 12:05:50”