What is journalctl Command in Linux?
The journalctl command in Linux is used to view and analyze logs collected by the systemd journal service (systemd-journald). It provides a centralized way to inspect system logs, service logs, kernel messages, and boot events without manually searching through multiple log files.
Unlike traditional logging systems that store logs in separate text files, journalctl queries logs stored in the systemd journal database, allowing administrators to filter logs by time, service, boot session, priority, process ID, and more.
How systemd-journald collects and stores logs
The systemd-journald service collects logs from multiple sources across the system and stores them in a structured journal database.
Log sources include:
- Kernel logs
- systemd service logs
- Syslog messages
- Standard output and error from services
- Audit and authentication logs
Instead of storing logs in plain text files, systemd-journald stores them in a binary journal format, which allows faster querying and filtering using journalctl.
Where journal logs are stored in Linux
Journal logs are typically stored in the following directories depending on system configuration.
Volatile logs (temporary logs stored in memory):
/run/log/journal
Persistent logs (stored across reboots):
/var/log/journal
If the persistent directory exists, systemd stores logs there. Otherwise, logs remain temporary and disappear after reboot.
You can check journal disk usage using:
journalctl --disk-usage
journalctl vs traditional Linux log files
Traditional Linux systems store logs in text files inside the /var/log directory, such as:
/var/log/syslog
/var/log/messages
/var/log/auth.log
These logs are usually managed by tools like rsyslog and rotated using logrotate.
The journalctl system differs in several ways:
| Feature | Traditional Logs | journalctl |
|---|---|---|
| Storage format | Plain text files | Binary journal database |
| Query capabilities | Limited (grep, tail) | Advanced filtering |
| Centralized logging | Multiple files | Unified journal |
| Structured metadata | No | Yes |
Because of these features, journalctl provides more powerful log analysis capabilities for modern Linux systems using systemd.
journalctl Command Syntax
The basic syntax of the journalctl command is:
journalctl [options] [filters]
By default, running journalctl without any options displays all logs collected by systemd-journald.
Example:
journalctl
This prints the entire journal log starting from the oldest entry.
journalctl Quick Reference Table
View logs
| Task | Command |
|---|---|
| View all system logs | journalctl |
| Show last 100 log entries | journalctl -n 100 |
| Show logs in reverse order | journalctl -r |
| Display logs without pager | journalctl –no-pager |
Follow logs in real time
| Task | Command |
|---|---|
| Follow logs continuously | journalctl -f |
| Follow logs for specific service | journalctl -u sshd -f |
| Follow logs from latest entry | journalctl -n 50 -f |
Filter logs by service
| Task | Command |
|---|---|
| Show logs for SSH service | journalctl -u sshd |
| Show logs for nginx service | journalctl -u nginx |
| Show logs for service from current boot | journalctl -u sshd -b |
Filter logs by time
| Task | Command |
|---|---|
| Show logs since today | journalctl –since today |
| Show logs since yesterday | journalctl –since yesterday |
| Show logs between two times | journalctl –since “2026-03-01” –until “2026-03-02” |
| Show logs for last hour | journalctl –since “1 hour ago” |
Filter logs by priority
| Task | Command |
|---|---|
| Show error messages only | journalctl -p err |
| Show warnings and above | journalctl -p warning |
| Show emergency level logs | journalctl -p emerg |
| Show logs within priority range | journalctl -p warning..crit |
Manage journal log storage
| Task | Command |
|---|---|
| Check journal disk usage | journalctl –disk-usage |
| Delete logs older than 7 days | journalctl –vacuum-time=7d |
| Limit journal size to 500MB | journalctl –vacuum-size=500M |
| Remove archived journal files | journalctl –vacuum-files=5 |
Viewing System Logs
View all system logs
To display all logs stored in the system journal, run the journalctl command without any options.
journalctl
This command prints every log entry recorded by systemd-journald, starting from the oldest entry to the most recent. The output includes logs generated by the kernel, system services, and user applications.
View last N log entries
If you only want to see the most recent log messages, you can limit the output using the -n option followed by the number of lines to display.
Example showing the last 100 log entries:
journalctl -n 100
This is similar to using tail on traditional log files and is useful when investigating recent system activity.
View logs in reverse order
By default, journalctl displays logs starting from the oldest entry. To display the newest logs first, use the -r option.
journalctl -r
This reverses the order of the output, making it easier to quickly view recent events without scrolling through older logs.
Follow logs in real time (journalctl tail)
You can monitor logs in real time similar to the tail -f command by using the -f option.
journalctl -f
This command continuously displays new log entries as they are generated. It is useful for monitoring system activity or debugging services as they run.
To stop following the logs, press Ctrl + C.
Show logs without pager
By default, journalctl uses a pager such as less to display output. If you want the logs to print directly to the terminal without pagination, use the --no-pager option.
journalctl --no-pager
This is helpful when redirecting output to scripts or when piping logs to other commands.
Display logs with detailed metadata
Journal entries contain additional metadata such as process ID, unit name, boot ID, and priority level. To view this extended information, use the verbose output format.
journalctl -o verbose
Verbose mode displays structured log fields and metadata, which can help during advanced troubleshooting or forensic analysis.
Viewing Logs by Boot
List all previous system boots
To display a list of all recorded system boots, use the following command:
journalctl --list-boots
This command shows boot sessions along with their boot IDs and timestamps. The first column represents the boot offset used to query logs from that boot.
Example output may look like:
-1 9d3c0e3... Mon 2026-03-01 08:15:02 – Mon 2026-03-01 10:02:21
0 a17c28b... Mon 2026-03-01 10:02:21 – Mon 2026-03-02 08:40:11
Here, 0 represents the current boot and -1 represents the previous boot.
View logs from current boot
To display logs generated since the current system boot, use:
journalctl -b
This is useful when troubleshooting problems that occurred after the most recent reboot.
View logs from previous boot
To inspect logs from the previous system boot, use the boot offset -1.
journalctl -b -1
You can also view logs from earlier boots using larger negative numbers.
Example:
journalctl -b -2
This displays logs from the boot session before the previous one.
View logs from specific boot ID
Instead of using numeric offsets, you can also specify the boot ID shown in the --list-boots output.
Example:
journalctl -b a17c28b5c9c34a89b3a2e1d2b4e8c2f1
This retrieves logs from that specific boot session.
View boot logs with time filter
Boot logs can also be combined with time filters to narrow down the output.
Example showing logs from current boot since a specific time:
journalctl -b --since "2 hours ago"
You can also specify both start and end times.
Example:
journalctl -b --since "2026-03-01 10:00:00" --until "2026-03-01 11:00:00"
This approach helps isolate events that occurred during a specific time window within a boot session.
Filtering Logs by Time
One of the most powerful features of the journalctl command is the ability to filter logs based on time. This allows administrators to quickly analyze system events that occurred during a specific period.
Time-based filtering is especially useful when diagnosing system crashes, service failures, or unexpected system activity.
Show logs since today
To display logs generated since the beginning of the current day, use the following command:
journalctl --since today
This command helps you quickly review system events that occurred today without scrolling through older logs.
Show logs since yesterday
To view logs starting from yesterday, run:
journalctl --since yesterday
This shows all log entries generated from the beginning of the previous day up to the current time.
Show logs within specific time range
You can specify a custom time expression to filter logs from a particular time onward.
Example:
journalctl --since "2026-03-01 10:00:00"
This command displays logs generated after the specified date and time.
Show logs between two timestamps
You can define both a start and end time to narrow down log entries to a precise window.
Example:
journalctl --since "2026-03-01 10:00:00" --until "2026-03-01 11:00:00"
This command returns logs generated between the specified start and end times.
Show logs for last hour or last day
journalctl also supports relative time expressions.
Example showing logs from the last hour:
journalctl --since "1 hour ago"
Example showing logs from the last day:
journalctl --since "1 day ago"
Relative time filtering is useful for quickly reviewing recent system activity.
Viewing Logs for a Specific Service
journalctl can filter logs for a specific systemd service unit, allowing administrators to troubleshoot individual services without scanning the entire system journal.
View logs for systemd service
To display logs for a particular systemd service, use the -u option followed by the service name.
Example showing logs for the SSH service:
journalctl -u sshd
This command displays all log entries generated by the specified service.
Follow logs for service in real time
To monitor logs for a service continuously, combine the -u option with the -f option.
Example:
journalctl -u sshd -f
This command behaves similar to tail -f, displaying new log entries as they are generated.
View logs for multiple services
journalctl allows filtering logs from multiple services by specifying multiple -u options.
Example:
journalctl -u sshd -u nginx
This displays logs generated by both the SSH and Nginx services.
View service logs for current boot
To display logs from a service for the current boot session only, combine the -u and -b options.
Example:
journalctl -u sshd -b
This is useful when troubleshooting issues that started after a system reboot.
Show logs for failed services
To inspect logs related to failed systemd services, you can filter logs by priority or investigate a specific failing unit.
Example checking logs for a failed service:
journalctl -u nginx
You can combine this with other filters to investigate service startup errors or crashes.
Filtering Logs by Priority (Log Level)
Each journal entry is assigned a priority level that indicates the severity of the message. journalctl allows filtering logs based on these priority levels.
Common log levels include:
| Priority | Description |
|---|---|
| emerg | Emergency condition |
| alert | Immediate action required |
| crit | Critical condition |
| err | Error message |
| warning | Warning message |
| notice | Normal but important event |
| info | Informational message |
| debug | Debugging information |
Show emergency level logs
To display only emergency-level logs, use the -p option.
journalctl -p emerg
These messages represent the most severe system events.
Show error level logs
To view logs with error severity:
journalctl -p err
This helps identify failures such as service crashes or configuration errors.
Show logs within priority range
You can also specify a range of priorities.
Example showing logs from warning to critical levels:
journalctl -p warning..crit
This returns messages with priority levels between warning and critical.
Show only warning messages
To display warning messages:
journalctl -p warning
Warning logs indicate potential issues that may require attention but are not necessarily critical.
Display debug level logs
To view detailed debugging information:
journalctl -p debug
Debug logs are useful for developers and administrators diagnosing complex issues.
Filtering Logs by Process, User, or Binary
Filter logs by process PID
You can view logs generated by a specific process using the _PID field.
Example:
journalctl _PID=1234
Replace 1234 with the process ID you want to investigate. This is useful when troubleshooting logs for a specific running process.
Filter logs by specific user
To display logs generated by a particular user account, use the _UID field.
Example:
journalctl _UID=1000
You can obtain the user ID using the following command:
id username
Filtering by user ID helps analyze activity generated by a specific user account.
Filter logs by executable path
You can also filter logs generated by a specific binary or executable.
Example:
journalctl /usr/sbin/sshd
This command displays all log messages generated by the sshd binary.
Filter logs using systemd unit fields
systemd stores metadata fields for each log entry. One commonly used field is _SYSTEMD_UNIT, which represents the service unit responsible for the log message.
Example:
journalctl _SYSTEMD_UNIT=sshd.service
This command filters logs generated by the specified systemd unit.
Combine multiple filters
journalctl supports combining multiple filters to narrow down results.
Example:
journalctl _SYSTEMD_UNIT=sshd.service _UID=0
This command displays logs generated by the sshd service for the root user.
Combining filters is helpful when investigating specific system events.
Viewing Kernel Logs
Display kernel logs using journalctl
To display only kernel messages from the journal, use the -k option.
journalctl -k
This command filters the journal to show only kernel-related log entries.
View kernel logs for current boot
You can combine the -k option with the -b option to display kernel logs generated during the current boot session.
journalctl -k -b
This helps diagnose hardware or driver issues that occur during system startup.
Compare journalctl kernel logs with dmesg
The dmesg command also displays kernel logs, but journalctl provides additional filtering capabilities.
Example using dmesg:
dmesg
Example using journalctl:
journalctl -k
journalctl allows filtering by time, priority, and boot session, which makes it more flexible for troubleshooting.
Filter kernel logs by time
You can combine kernel log filtering with time filters.
Example showing kernel logs from the last hour:
journalctl -k --since "1 hour ago"
This helps identify recent kernel events such as driver errors or hardware issues.
Viewing Detailed Log Output
Display logs in verbose mode
Verbose mode displays detailed metadata associated with each log entry, such as process ID, unit name, boot ID, and priority.
Example:
journalctl -o verbose
This output format is useful when performing deep analysis of system logs.
Show logs with explanation text
You can include explanatory messages for certain log entries using the -x option.
Example:
journalctl -x
This adds helpful descriptions for some log messages, making them easier to understand during troubleshooting.
Show logs in JSON format
journalctl can output logs in JSON format, which is useful for automation or integration with monitoring tools.
Example:
journalctl -o json
This structured output can be parsed by scripts or log analysis systems.
Display logs with custom output format
journalctl supports several output formats that control how log entries are displayed.
Example using short output format:
journalctl -o short
Example showing logs in ISO timestamp format:
journalctl -o short-iso
Custom output formats allow administrators to view logs in a format suitable for analysis or reporting.
Managing Journal Log Storage
Systemd stores journal logs either in memory or on disk depending on the system configuration. Over time, these logs can consume significant storage space, so administrators should periodically monitor and manage journal log usage.
Check disk usage of journal logs
To check how much disk space is used by journal logs, run:
journalctl --disk-usage
This command displays the total disk space consumed by archived and active journal files.
Example output:
Archived and active journals take up 420.0M on disk.
This helps determine whether cleanup is required.
Limit journal log size
You can reduce disk usage by limiting the total size of archived journal logs.
Example limiting journal logs to 200MB:
journalctl --vacuum-size=200M
This removes archived journal files until the total size falls below the specified limit.
Remove old journal logs
Another way to clean up logs is to remove older journal files.
Example removing archived journals older than 7 days:
journalctl --vacuum-time=7d
This deletes logs older than the specified time period.
Remove logs older than specific time
You can specify a custom duration such as days, weeks, or months.
Example removing logs older than one month:
journalctl --vacuum-time=30d
This is useful on servers where log files grow quickly.
Combine size and time cleanup
You can combine size and time limits to enforce stricter log retention policies.
Example:
journalctl --vacuum-size=500M --vacuum-time=14d
This ensures journal logs remain below 500MB and removes entries older than two weeks.
Practical Troubleshooting with journalctl
The journalctl command is widely used for diagnosing system issues and investigating service failures. By filtering logs based on services, time ranges, or priorities, administrators can quickly locate relevant log entries.
Diagnose service startup failures
If a systemd service fails to start, journalctl can be used to inspect the service logs.
Example checking logs for a failed service:
journalctl -u nginx
This displays logs generated by the nginx service, which often contain error messages explaining why the service failed.
Investigate SSH login attempts
To analyze SSH login activity, inspect logs from the SSH service.
Example:
journalctl -u sshd
You can combine this with time filters for recent login activity.
Example:
journalctl -u sshd --since "1 hour ago"
This helps identify login attempts or authentication errors.
Check system crashes or kernel issues
Kernel-related problems can be analyzed using kernel logs.
Example:
journalctl -k
This displays kernel messages such as hardware initialization, driver errors, and system crashes.
Analyze authentication failures
Authentication failures and user login issues are often recorded in system logs.
Example searching for authentication-related entries:
journalctl | grep "authentication failure"
This helps identify incorrect login attempts or security events.
Troubleshoot failed systemd units
To troubleshoot services that failed during boot, check logs from the current boot session.
Example:
journalctl -b -p err
This command displays error-level messages from the current boot.
These logs often reveal service failures or configuration problems.
Troubleshooting journalctl Errors
Although journalctl is reliable, administrators may occasionally encounter issues while viewing logs. The following sections explain common problems and their solutions.
journalctl shows no logs
If journalctl does not display any logs, the journal service may not be storing logs persistently.
Check whether the persistent log directory exists:
ls /var/log/journal
If the directory is missing, logs may only be stored in memory and will disappear after reboot.
Permission denied while viewing logs
Non-root users may receive permission errors when accessing system logs.
Example error:
Failed to open journal: Permission denied
You can run the command with elevated privileges:
sudo journalctl
Alternatively, add the user to the systemd-journal group.
Journal logs missing after reboot
If logs disappear after a reboot, persistent logging may not be enabled.
Create the persistent journal directory:
sudo mkdir -p /var/log/journal
Then restart the journald service:
sudo systemctl restart systemd-journald
This enables logs to be stored permanently.
Journal logs consuming too much disk space
If journal logs consume excessive disk space, check usage:
journalctl --disk-usage
Then reduce log size using:
journalctl --vacuum-size=200M
This removes older archived logs.
Persistent vs volatile journal logs
Systemd supports two types of journal storage.
Volatile logs are stored in memory:
/run/log/journal
Persistent logs are stored on disk:
/var/log/journal
Persistent logging ensures logs remain available even after system reboot.
Frequently Asked Questions
1. What is the journalctl command used for?
The journalctl command in Linux is used to view and filter logs collected by the systemd-journald service. It allows administrators to inspect system logs, service logs, kernel logs, and boot messages.2. How do I follow logs in real time using journalctl?
You can use the -f option with journalctl to follow logs in real time, similar to tail -f. For example, run journalctl -f to continuously display new log entries as they are generated.3. How can I view the last 100 log lines using journalctl?
Use the -n option to show the last number of log entries. For example, journalctl -n 100 will display the last 100 log messages from the system journal.4. How do I filter logs by service using journalctl?
You can filter logs by systemd service using the -u option. For example, journalctl -u sshd.service shows logs related to the SSH daemon service.5. Where are journalctl logs stored in Linux?
Journal logs are stored in /run/log/journal for volatile logs and /var/log/journal for persistent logs if persistent storage is enabled in systemd-journald configuration.Summary
The journalctl command is the primary tool used to view and analyze logs generated by the systemd-journald logging service in modern Linux distributions. It provides a centralized way to inspect system logs, kernel messages, service logs, authentication events, and boot information.
Unlike traditional log files stored under /var/log, journalctl allows powerful filtering based on time, service name, boot session, process ID, priority level, and user account. This makes it easier for administrators to troubleshoot service failures, investigate login attempts, diagnose kernel issues, and monitor system activity.
With features such as real-time log monitoring, structured metadata filtering, and journal log cleanup options, journalctl has become an essential tool for system administrators working with systemd-based Linux systems.
Understanding how to filter logs by time ranges, services, boot sessions, and priorities allows faster debugging and more efficient system maintenance.
