What Does journalctl Mean?
On This Page
What do you want to do?
Quick Definition
Journalctl is a command that lets you look at logs on a Linux computer. It shows messages from the system and from programs that are running. You can use it to see what happened when something went wrong, like a crash or a network problem. It is helpful for figuring out why a service stopped or why an error occurred.
Common Commands & Configuration
journalctl -u sshd.service --since '2023-10-01' --until '2023-10-02' -p errShows error-level log entries for the SSH daemon within a specific date range. Error-level includes err, crit, alert, and emerg priorities.
Tests ability to combine service filtering, time range, and priority filtering to pinpoint authentication errors or connection failures.
journalctl -b -1 -p 3Displays priority 3 (error) and more severe messages from the previous boot session. -b -1 refers to the boot before the current one.
Commonly tested scenario: diagnosing a crash or failure that required a reboot. Understanding boot indexing is crucial.
journalctl --vacuum-size=200MManually reduces total journal file size to 200 megabytes by removing oldest entries first. Does not affect entries under the threshold.
Tests knowledge of log volume management and the vacuum command to free disk space without deleting recent logs.
journalctl -o json-pretty -u apache2.service | grep '"MESSAGE"'Outputs Apache2 service logs in pretty JSON format, then extracts the message field. Useful for programmatic analysis or feeding into monitoring tools.
Exams may test output formatting options (-o) and how to extract structured data for scripting or integration.
journalctl -k -p emergShows only kernel messages with emergency priority, the most critical kernel issues. -k filters for kernel log entries.
Tests filtering kernel-specific logs and understanding priority levels, especially for hardware or driver failures.
journalctl _PID=1234 _COMM=sshdDisplays logs from process ID 1234 where the command name is sshd. Uses journal fields for precise filtering.
Tests advanced field-based filtering, often used to trace a specific process's activity during an incident.
sudo journalctl --verifyVerifies integrity of all journal files, checking for corruption and validating Forward Secure Seals if enabled.
Appears in security-focused exam questions about log integrity and Forward Secure Sealing (FSS).
journalctl appears directly in 12exam-style practice questions in Courseiva's question bank — one of the most-tested concepts on Cisco CCNA. Practise them →
Must Know for Exams
Journalctl is prominently featured in the Linux Professional Institute (LPI) exams, specifically LPIC-1 (101 and 102), and in Red Hat Certified System Administrator (RHCSA) exam objectives. In the LPIC-1 102 exam, topic 108.2 covers system logging, including journalctl, where candidates must know how to view, filter, and persist logs. The RHCSA exam includes objectives related to managing services with systemd, which necessarily involves using journalctl to check service status and logs.
In CompTIA Linux+, journalctl appears in domain 4 (System Operation and Maintenance) under logging and monitoring. Candidates are expected to know how to use journalctl to locate boot issues, examine authentication logs, and export logs for analysis. The exam may present a scenario where a service fails to start, and the candidate must choose the correct journalctl command to identify the cause.
Other IT certifications that touch on journalctl include the AWS Certified SysOps Administrator (where Linux-based EC2 instances use systemd) and the Google Cloud Professional Cloud Architect (for troubleshooting Compute Engine instances). While not the primary focus, knowing journalctl can help answer troubleshooting-related questions. In all exams, the emphasis is on practical usage: filtering by unit, time, and priority, and understanding the difference between persistent and volatile journal storage. Exam questions often include command syntax options such as -u, -p, --since, --until, and -n.
Simple Meaning
Imagine your computer keeps a diary of everything that happens while it is on. Every time a program starts, stops, or runs into trouble, it writes a note in that diary. Journalctl is the tool you use to open that diary and search through the entries. Instead of flipping through hundreds of pages, you can ask journalctl to show you only entries from a certain time, or only entries that contain a specific word like error or fail.
For example, if your internet connection drops and a website stops working, journalctl can show you the exact moment the network service logged a problem. You do not need to know where the log files are stored because journalctl finds them for you. It also color-codes messages so serious errors stand out in red. This makes it much easier to quickly spot problems.
The diary is not stored in one big messy pile. The systemd journal organizes everything by time and by which program created the message. You can also use journalctl to see logs from the current boot session only, which is very helpful when troubleshooting a problem that just happened. If you need to look further back, journalctl can show logs from previous boots as long as they have been saved. This is like being able to read yesterday's diary entry even though the computer has been turned off and on again.
Full Technical Definition
Journalctl is the command-line utility for querying and displaying logs from the systemd journal, a binary logging subsystem introduced with systemd. Unlike traditional text-based log files in /var/log, the journal stores log data in a structured, indexed, binary format. This allows journalctl to perform fast searches, filter by time ranges, systemd units, priority levels, kernel messages, and more. The journal uses the sd-journal API to read and write entries, which include metadata fields such as _PID, _COMM, _SYSTEMD_UNIT, PRIORITY, MESSAGE, and SYSLOG_IDENTIFIER.
Entries are written by systemd-journald, a daemon that collects log messages from various sources: syslog calls, kernel log buffers (kmsg), structured journal messages from applications using the sd-journal API, and stdout/stderr output from systemd services. The journal can be stored persistently in /var/log/journal (if the directory exists) or held only in memory in /run/log/journal. By default, many Linux distributions use persistent storage, which preserves logs across reboots. The journal size is capped to prevent disk filling, typically to 10% of the file system or a maximum size like 4 GB, configurable via systemd-journald.conf.
Common journalctl commands include journalctl -u nginx.service to show logs for a specific systemd unit, journalctl --since yesterday to filter by time, journalctl -p err to show only messages of priority error and above, and journalctl -k to show kernel messages. Journalctl supports output in various formats using the -o flag: short, short-iso, verbose (showing all metadata fields), json, and export. The -f flag follows logs in real time, similar to tail -f. For debugging, the -x flag adds explanatory help messages for log entries when available. Journalctl is essential for system administrators and IT professionals when diagnosing service failures, boot problems, and security events. It is also used in scripting and monitoring pipelines because it can be combined with grep, awk, and other text-processing tools, though direct filtering via journalctl's own options is preferred for performance.
Real-Life Example
Think of journalctl as the security camera system for a large office building. The building has cameras in every hallway, every meeting room, and every entrance. Each camera records everything that happens: people walking by, doors opening, alarms sounding. The recordings are stored in a central server, but there are hundreds of hours of footage.
If the building manager wants to know why a fire alarm went off at 2:00 AM last Tuesday, they cannot watch every single camera feed for the whole night. Instead, they use a search system that can pull up only the footage from that specific time and only the cameras near the fire alarm panel. That is what journalctl does for system logs.
In the IT world, the building manager is the system administrator, the cameras are the different services and system components (like the web server, the database, the kernel), and the central server is the systemd journal. When something breaks, you do not want to read every log file manually. You use journalctl to filter by time, by service, and by severity, so you can focus on exactly the footage that matters. Just like the security system can highlight motion events, journalctl can color-code critical errors in red.
Why This Term Matters
In IT, logging is the primary source of truth when diagnosing failures. Without journalctl, administrators would need to navigate multiple log files spread across /var/log, each with different formats and rotation policies. Journalctl centralizes all logs into a single, queryable repository with a consistent interface. This matters because when a production server goes down, time is money. The ability to quickly run journalctl -u myservice --since 10 minutes ago and see exactly what happened reduces mean time to resolution.
Journalctl also matters for compliance and auditing. Security professionals use it to review login attempts, sudo commands, and service starts. Because the journal can be made persistent and can include cryptographic verification (via forward-secure sealing), logs become admissible evidence in incident response. Many IT certification exams, including the Linux Professional Institute (LPI) exams and Red Hat certifications, test candidates on journalctl because it reflects modern Linux administration practices.
journalctl integrates with systemd's dependency tracking. When a service fails, journalctl can show you not just that service's logs but also logs from its dependencies. This holistic view is something traditional syslog cannot provide without manual correlation. For anyone managing Linux servers, mastering journalctl is not optional; it is a core skill.
How It Appears in Exam Questions
Journalctl questions typically fall into three categories: command syntax, scenario-based troubleshooting, and log analysis. In syntax questions, you might be asked: Which command shows all messages from the sshd service since yesterday? The correct answer would be journalctl -u sshd.service --since yesterday. Another variant: Which flag limits output to the last 50 lines? The answer is -n 50.
Scenario-based questions present a problem, such as: A web server is not responding. Which journalctl command would help you find the most recent error messages from the Apache service? You would use journalctl -u httpd.service -p err -n 20. The exam might also ask how to follow logs in real time while filtering for a specific unit: journalctl -u network.service -f.
Log analysis questions might show a snippet of journalctl output and ask what caused a service crash. For example, the output might show a segmentation fault in the application. The candidate would need to interpret the MESSAGE field and possibly correlate it with a previous log entry showing an OOM (out-of-memory) killer event. These questions test not just command knowledge but also the ability to diagnose issues from log content.
Another common pattern involves boot performance. The candidate might be asked how to check logs from the previous boot to see why a service failed to start. The command is journalctl -b -1 (or journalctl --boot=-1). Similarly, listing all available boots can be done with journalctl --list-boots. These appear in troubleshooting scenarios where the system rebooted unexpectedly.
Practise journalctl Questions
Test your understanding with exam-style practice questions.
Example Scenario
Imagine you are studying for the RHCSA exam. You have set up a web server using Nginx on a CentOS virtual machine. You start the service with systemctl start nginx, but when you try to access the website from a browser, you get a connection refused error. You suspect something is wrong with the Nginx configuration.
You decide to use journalctl to examine the Nginx logs. You run journalctl -u nginx.service -p err --since 10 minutes ago. The output shows an error message: bind() to 0.0.0.0:80 failed (98: Address already in use). This tells you that port 80 is already occupied, likely by another web server. You then run journalctl -u nginx.service -p info --since 10 minutes ago to see more details, and you notice that Apache was started earlier.
Now you know the solution: you need to stop Apache first with systemctl stop httpd, then restart Nginx. Without journalctl, you might have spent time checking firewall rules or browsing through multiple log files. This scenario reflects a common exam question where you must use journalctl to identify a port conflict. The exam would expect you to know the exact command to filter by unit and error level.
Common Mistakes
Using journalctl without any filters and trying to manually search through all logs.
The journal can contain millions of lines, making manual search inefficient and time-consuming.
Always filter by time, unit, or priority using options like --since, -u, or -p.
Assuming journalctl shows all logs from all boots by default.
By default, journalctl shows logs from the current boot only. Older boots are not shown unless you specify -b or --boot.
Use journalctl --list-boots to see available boots, then use journalctl -b -1 for the previous boot.
Using grep instead of journalctl's native filtering options for large log queries.
Piping journalctl output to grep bypasses the efficient indexing of the journal, causing slower searches and possibly missing metadata fields.
Use journalctl options like -u, -p, --since, or -g (for grep-like pattern matching within the journal) for faster and more accurate results.
Forgetting that the journal may not be persistent and logs from previous boots are lost after reboot.
If /var/log/journal does not exist, logs are stored only in /run/log/journal, which is cleared on reboot.
Create the directory /var/log/journal and restart systemd-journald to enable persistent logging.
Exam Trap — Don't Get Fooled
{"trap":"The exam question asks which command shows the most recent log messages from the sshd service, and the answer choices include journalctl -u sshd and journalctl -u sshd.service -n 10.","why_learners_choose_it":"Learners may choose journalctl -u sshd because it seems simpler, and they think it shows recent logs by default."
,"how_to_avoid_it":"Remember that journalctl -u sshd shows all logs from that unit, which could be thousands of lines. The -n flag limits output to the most recent entries. Always look for options that control output volume."
Commonly Confused With
Dmesg specifically shows kernel ring buffer messages, which are usually related to hardware and driver issues. Journalctl with the -k flag also shows kernel messages, but journalctl can show much more than the kernel buffer.
To see kernel messages from the current boot, you could use either dmesg or journalctl -k, but journalctl -k allows filtering by time and severity.
Tail follows a text-based log file in real time. Journalctl -f does the same but from the binary journal, and it can filter by unit, priority, or boot session without needing to navigate to a specific file.
Instead of tail -f /var/log/syslog, you can run journalctl -f -u nginx.service to follow only Nginx logs.
Systemctl status shows the current state of a service along with a few recent log entries. Journalctl provides full access to all past logs with much more flexible filtering.
Systemctl status sshd shows if the service is running and the last few log lines. Journalctl -u sshd.service --since yesterday shows all SSH logs from yesterday.
Step-by-Step Breakdown
Invoke journalctl without arguments
Running journalctl alone displays all systemd journal entries from the current boot, starting with the oldest. This is rarely useful alone but serves as the base command.
Filter by systemd unit with -u
Using -u followed by a unit name (like sshd.service) limits output to logs generated by that specific service. This is the most common filter because troubleshooting usually involves a single service.
Filter by priority with -p
The -p flag filters by log level: emerg, alert, crit, err, warning, notice, info, debug. Using -p err shows only errors and above, reducing noise.
Limit output volume with -n or --since
The -n flag shows the last N entries, and --since or --until restrict by time (e.g., --since '1 hour ago'). These prevent overwhelming output.
View previous boot logs with -b
The -b flag with an offset (0 for current, -1 for previous) shows logs from that boot. Use --list-boots first to see all available boots.
Practical Mini-Lesson
To use journalctl effectively in a real IT environment, you must understand the difference between persistent and volatile logging. By default, if /var/log/journal does not exist, systemd-journald stores logs in /run/log/journal, which is a tmpfs and is cleared on every reboot. For production servers, you should enable persistent logging by creating the directory and restarting the daemon: sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald. This ensures you can investigate issues that caused previous reboots.
Another practical skill is exporting logs for analysis. Use journalctl -o json-pretty to output logs in a structured JSON format that can be ingested by log management tools like Elasticsearch, Splunk, or Graylog. For example: journalctl -u nginx.service --since yesterday -o json-pretty > nginx_logs.json. This allows teams to centralize logs and correlate events across multiple servers.
A common mistake is ignoring rate limiting. Systemd-journald has built-in rate limiting that can suppress repeated messages. If you suspect missing log entries, check /etc/systemd/journald.conf for RateLimitIntervalSec and RateLimitBurst parameters. You may need to raise these values during high-volume events.
Finally, remember that journalctl commands can be combined with other tools in pipelines for automation. For example, a monitoring script could run journalctl -p err --since 5 minutes ago --quiet and alert if output is not empty. However, for performance, avoid piping to grep when journalctl's own filtering options suffice. The journal is indexed; using grep defeats that advantage.
Mastering journalctl Filtering Techniques for Efficient Log Analysis
The journalctl command is a powerful utility for querying and displaying logs collected by systemd-journald, the logging subsystem in modern Linux distributions. While simply running journalctl without arguments dumps the entire log history, the true skill lies in applying precise filters to isolate relevant entries. This section explores essential filtering techniques that IT professionals must master for system management and troubleshooting.
Time-based filtering is one of the most common needs. The --since and --until flags allow you to specify a datetime range, accepting formats like '2023-10-01 12:00:00', 'yesterday', 'today', or relative terms such as '1 hour ago' or '-1d'. Combining these flags, as in journalctl --since '2023-10-01' --until '2023-10-02', narrows the output to a specific window. This is critical when diagnosing transient issues that occurred at a known time, such as a service failure during a deployment window.
Filtering by service or unit is equally vital using the -u option. For example, journalctl -u nginx.service isolates all logs related to the Nginx web server. This is more efficient than grepping the full journal, as it uses systemd's internal indexing. You can also combine multiple units: journalctl -u sshd.service -u fail2ban.service helps correlate authentication and intrusion prevention entries. The _SYSTEMD_UNIT field can be used with the _PID field to trace logs from a specific process instance.
Priority level filtering helps separate informational messages from errors. Journal entries have syslog priority levels from 0 (emerg) to 7 (debug). The -p flag accepts a level name or number. For instance, journalctl -p err filters for error and more severe levels (err, crit, alert, emerg). You can combine this with time filters: journalctl -p 3 --since '2023-10-01' --until '2023-10-02' shows all error-level entries in that date range. This is invaluable for quickly identifying critical issues without noise.
Advanced filtering uses journal fields like _PID, _UID, _COMM, and _EXE. For example, journalctl _PID=1234 shows logs from a specific process ID. The --field flag lists all available field names: journalctl --field _TRANSPORT reveals possible transport mechanisms (driver, stdout, kernel, journal). Using _BOOT_ID lets you isolate logs from a particular boot session, essential for analyzing boot-time failures. The grep-like behavior can be achieved with -g for global pattern matching, e.g., journalctl -g 'error.*403'.
Output formatting is another crucial filtering aspect. The -o flag controls output style. Options include short (default), short-iso (ISO timestamps), verbose (shows all fields), json, and json-pretty. json-pretty is particularly useful for programmatic consumption or exporting log data to monitoring tools. For real-time monitoring, the -f flag (follow) streams new entries. Combining -f with -u creates a live tail of service logs: journalctl -u httpd.service -f.
Finally, boot and kernel-specific filters are essential for system troubleshooting. journalctl -b lists logs from current boot; -b -1 shows previous boot. This helps diagnose issues that required a reboot. For kernel messages, journalctl -k filters only kernel log entries. During hardware troubleshooting, combining -k with -p err isolates kernel errors. Mastering these filtering techniques transforms journalctl from a simple log viewer into a precision diagnostic instrument, a skill highly valued in IT certifications and real-world system administration.
Understanding journalctl Log Storage and Volume Management
Effective system management requires understanding how systemd-journald stores logs and how journalctl interacts with this storage. By default, journal logs are stored in binary format under /var/log/journal/ if persistent logging is enabled, or in /run/log/journal/ for volatile storage that resets on reboot. This section explains the storage mechanics, configuration options, and volume control techniques that are vital for troubleshooting and certification exams.
The journal is stored as a series of binary journal files with a .journal extension. These files are automatically rotated and compressed using LZ4 or XZ compression to save space. The journalctl command reads from these files, presenting a unified view. The --header option displays metadata about the current journal, including file size, number of entries, and ranges of timestamps and sequence numbers. This information helps administrators assess log volume and verify data integrity.
Log volume directly impacts disk usage, especially on systems generating extensive logs (e.g., web servers, databases). The /etc/systemd/journald.conf file controls storage behavior. Key settings include Storage= (auto, persistent, volatile, none), SystemMaxUse= (maximum disk space for journal files, e.g., SystemMaxUse=500M), and SystemKeepFree= (minimum free space reserved for other uses). Setting RuntimeMaxUse= controls volatile log size. Compression options are set via Compress= (yes/no) and Seal= (for Forward Secure Sealing). Understanding these parameters allows administrators to prevent disk-full scenarios where logs could cause system instability.
Vacuuming is the primary method for manual log cleanup. Journalctl offers two vacuum commands: --vacuum-size=SIZE and --vacuum-time=TIME. For example, journalctl --vacuum-size=200M reduces journal files to a total of 200 megabytes, removing the oldest entries first. Similarly, journalctl --vacuum-time=7d removes journal entries older than one week. These commands are non-destructive; they only remove entries that meet the criteria, leaving newer entries intact. The --rotate option forces immediate log rotation (closing current file and starting a new one) without deleting data, which is useful before taking a backup or applying configuration changes.
Persistent vs. volatile storage affects data availability. On many systems, the directory /var/log/journal is created only after touching /var/log/journal/ with root permissions. Without it, logs reside in /run/log/journal and are lost on reboot. Certification scenarios often test the ability to persist logs by creating this directory and restarting systemd-journald. The command mkdir -p /var/log/journal followed by systemctl restart systemd-journald enables permanent logging. This ensures log data survives for post-mortem analysis of system crashes.
Forward Secure Sealing (FSS) is an advanced feature that ensures log integrity. When Seal=yes in journald.conf and journalctl --setup-keys is run, each entry is cryptographically sealed. Verification is done with journalctl --verify, which checks seals and reports any tampering. While not commonly used in all environments, it appears in security-focused certification questions, testing understanding of log immutability.
Finally, forwarding logs to remote servers impacts storage locally. The ForwardToSyslog= and ForwardToWall= options control local forwarding. For centralized logging, journald can forward to syslog, which then sends to a remote collector. Alternatively, using journalctl --merge combines logs from multiple machines. Managing log volume is not just about storage; it's about strategic retention, compression, and archival to meet auditing and compliance requirements. Mastery of these concepts ensures logs are available when needed without exhausting system resources.
Troubleshooting Clues
Symptom:
Symptom:
Symptom:
Symptom:
Symptom:
Memory Tip
Think JCTRL: Journal, Command, Time, Unit, Real-time, Levels of priority.
Learn This Topic Fully
This glossary page explains what journalctl means. For a complete lesson with labs and practice, see the topic guide.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
Quick Knowledge Check
1.Which journalctl option filters logs to show only entries from the previous system boot?
2.An administrator wants to reduce the journal disk usage to 300 MB by removing the oldest entries. Which command should they run?
3.Which command shows only kernel messages with priority err (error) or higher?
4.What is the purpose of the Forward Secure Sealing (FSS) feature in systemd-journald?
5.To persistently save journal logs across reboots, which directory must exist?
6.Which journalctl command will display logs from the current boot session in a format that includes ISO timestamps?
Frequently Asked Questions
Can journalctl show logs from a specific user?
Yes, use journalctl _UID=1000 to show logs for a specific user ID. You can find the UID with the id command.
Is it possible to view logs from a specific date range?
Yes, use --since and --until together, for example: journalctl --since '2025-01-01 00:00:00' --until '2025-01-02 00:00:00'.
Do I need root privileges to use journalctl?
Basic usage does not require root, but viewing logs from other services or previous boots often requires sudo.
How do I clear old journal logs to free up disk space?
Use journalctl --vacuum-size=200M to reduce the journal size to 200 MB, or --vacuum-time=7d to keep only the last 7 days.
What is the difference between journalctl -u and journalctl _SYSTEMD_UNIT?
They are mostly equivalent. -u is a convenience filter that matches the unit name, while _SYSTEMD_UNIT is a specific field in the journal. The output is often the same.
Can journalctl output logs in syslog format?
Yes, use -o short-syslog or -o short-iso to get output that resembles traditional syslog messages.
Summary
Journalctl is the essential command-line tool for querying the systemd journal on modern Linux systems. It provides a centralized, indexed, and filterable interface to all system and application logs, replacing the need to manually search through multiple text files in /var/log. By mastering journalctl, IT professionals can rapidly diagnose service failures, boot problems, and security events, reducing downtime and improving system reliability.
For certification candidates, journalctl appears across LPIC-1, RHCSA, and CompTIA Linux+ exams, often in scenarios that require filtering by unit, time, or priority. Understanding the differences between persistent and volatile logging, and knowing how to export logs for analysis, are practical skills that translate directly to real-world administration.
The key exam takeaway is to always filter your journalctl queries to avoid information overload. Use -u for unit, -p for priority, --since for time, and -n for limiting output. Avoid relying solely on grep when native options exist, and remember to check for persistent logging if logs disappear after a reboot. With these skills, you will be well-prepared to answer troubleshooting questions on any certification exam.