How to Use the Command 'journalctl' (with Examples)

journalctl is a powerful command-line tool for viewing and managing logs in systems that use systemd. It allows you to query and display logs generated by various system services, making it an essential utility for system administrators and developers for troubleshooting. With journalctl, you can filter logs by time, priority, and other criteria, delete old logs, and more. Below are various use cases demonstrating the versatility of journalctl, complete with explanations and example outputs.

Use Case 1: Show All Messages with Priority Level 3 (Errors) from This Boot

Code:

journalctl -b --priority=3

Motivation:

This use case is particularly useful when you need to quickly identify and address issues that are critical to system operation. Priority level 3 corresponds to “errors,” meaning you can easily review all error messages generated since the system last booted, focusing on faults that might affect system health.

Explanation:

• -b: This option limits the log entries to the current boot session. This is particularly useful to zone in on logs relevant to issues occurring since the last time the system was started.
• --priority=3: This filter displays only log messages categorized as “errors.” In syslog severity levels, priority level 3 is designated for errors, which typically need immediate attention.

Example Output:

Jul 04 09:15:32 mysystem kernel: [error message 1]
Jul 04 09:15:35 mysystem systemd: Failed to start xyz.service
Jul 04 09:20:41 mysystem application: Error encountered in module abc

Use Case 2: Delete Journal Logs Which Are Older Than 2 Days

Code:

journalctl --vacuum-time=2d

Motivation:

Managing disk space is crucial for maintaining an efficient and operable system. Older logs can take up significant space and might be unnecessary to keep. This command helps in automatically cleaning up logs that are older than 2 days, conserving disk space and enhancing system performance.

Explanation:

• --vacuum-time=2d: This parameter deletes logs that are older than the specified time frame, “2d” here representing 2 days. It automatically calculates the age of logs and removes those that are no longer needed, based on this criterion.

Example Output:

Vacuuming done, freed 300 MB space from journal logs.

Use Case 3: Show Only the Last N Lines and Follow New Messages

Code:

journalctl --lines N --follow

Motivation:

When you’re debugging or monitoring services, you often need to inspect recent log messages as well as keep an eye on new logs as they appear. This functionality acts much like tail -f for traditional syslog files, but tailored for the systemd journal.

Explanation:

• --lines N: Specifies the number of lines you want to view initially. Replace N with the number of recent log entries you’re interested in.
• --follow: This command continuously displays new log entries as they are generated, providing real-time log updates useful for monitoring.

Example Output:

Jul 05 10:12:30 mysystem kernel: [new log entry...]
Jul 05 10:12:32 mysystem kernel: [new log entry...]

Use Case 4: Show All Messages by a Specific Unit

Code:

journalctl --unit unit

Motivation:

Often, it’s necessary to isolate logs from a particular service or application, known as a unit in systemd terminology. This is crucial for debugging and performance monitoring, especially when a specific service fails or behaves unexpectedly.

Explanation:

• --unit unit: Replaces ‘unit’ with the name of the systemd unit you want to inspect. This option fetches logs relevant only to the specified unit, which helps in focused troubleshooting.

Example Output:

Jul 05 13:45:22 mysystem nginx.service: Starting nginx...
Jul 05 13:45:23 mysystem nginx.service: Started nginx.

Use Case 5: Show Logs for a Given Unit Since the Last Time It Started

Code:

journalctl _SYSTEMD_INVOCATION_ID=$(systemctl show --value --property=InvocationID unit)

Motivation:

Sometimes, you need to pinpoint exactly what happened during the last instance a service or unit was started. This command correlates the InvocationID of the current or most recent service run, helping trace logs during that specific execution.

Explanation:

• _SYSTEMD_INVOCATION_ID: This references a unique identification for each execution of a unit, allowing for precise log filtering.
• $(systemctl show --value --property=InvocationID unit): Retrieves the current or last InvocationID for the specified unit, ensuring logs are sourced from the appropriate timeframe.

Example Output:

Jul 05 14:00:00 mysystem python.service: Process started.
Jul 05 14:00:05 mysystem python.service: Executing script...

Use Case 6: Filter Messages Within a Time Range

Code:

journalctl --since now|today|yesterday|tomorrow --until "YYYY-MM-DD HH:MM:SS"

Motivation:

Filtering logs by time range is indispensable for comprehensive analysis and reporting. This can assist in identifying patterns over time or zeroing in on events surrounding a known occurrence.

Explanation:

• --since: Sets the start of the time range for log retrieval. Options include relative terms like now, today, yesterday, or timestamps.
• --until: Defines the end of the time range to search for logs. This can be a specific date and time in the format “YYYY-MM-DD HH:MM:SS”.

Example Output:

Jul 05 08:00:00 mysystem systemd: Starting daily activities...
Jul 05 08:05:10 mysystem application: Scheduled task executed

Use Case 7: Show All Messages by a Specific Process

Code:

journalctl _PID=pid

Motivation:

Tracking logs for an individual process can be fundamental when debugging or analyzing the process’s behavior. This capability simplifies diagnosing specific process issues without the noise of unrelated logs.

Explanation:

• _PID=pid: Filter logs by the Process ID (pid). This command will display all the log entries associated with the given process ID, useful for focused diagnostics.

Example Output:

Jul 05 12:00:00 mysystem application[1234]: Starting process...
Jul 05 12:00:05 mysystem application[1234]: Process completed.

Use Case 8: Show All Messages by a Specific Executable

Code:

journalctl path/to/executable

Motivation:

Systems can run multiple executables, and you might need logs specifically related to a single executable to debug or understand its impact on the system. Focusing on one executable’s logs is essential for performance analysis and debugging.

Explanation:

• path/to/executable: Displays log entries associated with the specified executable. By providing the path, you ensure that logs directly related to the executable’s runtime are filtered and shown.

Example Output:

Jul 05 11:05:00 mysystem /usr/bin/example: Started successfully
Jul 05 11:06:00 mysystem /usr/bin/example: Processing data...

Conclusion:

journalctl is a comprehensive tool designed for effectively managing and querying logs in systems using systemd. By leveraging different options and filters, users can tailor their log viewing experience, enabling them to troubleshoot and analyze system events with precision and efficiency. Whether you’re a system administrator, developer, or tech enthusiast, mastering journalctl commands will bolster your ability to maintain and optimize system performance.