How to use journalctl to inspect Linux system logs
Learn how to inspect service logs on Linux using journalctl. Master time, priority, and systemd unit filters to troubleshoot issues quickly.
Summary
- Journalctl provides a unified and centralized interface for querying binary system logs.
- Filtering by systemd unit is the most effective way to isolate errors from a specific service.
- Querying logs by time intervals avoids manual navigation through lengthy text files.
- Priority levels allow hiding informational messages to focus only on critical failures.
- Real-time viewing is essential for diagnosing unexpected behaviors during service startup.
What is journalctl and why should you use it
In the Linux world, understanding what happens under the hood is vital for server survival. In the past, we had to navigate through dozens of text files in /var/log/, trying to correlate events. With the widespread adoption of systemd, journalctl was born. It is the utility that interacts with the 'journal', a structured binary repository that collects logs from almost all system components. Unlike plain text logs, the journal allows for fast, indexed searches, making troubleshooting much less painful.
Mastering basic filters for troubleshooting
When a service fails, you rarely want to see everything that happened on the server. The most common way to use the command is to filter by service unit. If you suspect that Nginx or a custom service stopped responding, just isolate the log. In practice, this means you no longer waste time filtering random strings with grep. Furthermore, when investigating bottlenecks, we often need a global view of resources, which complements using tools like htop to find heavy processes.
Filtering by time and priority
The real power appears when we combine filters. If the error occurred 10 minutes ago, there is no point in reading the entire log since boot. With the --since flag, you define the temporal starting point. Priority, represented by the -p flag, helps filter out noise. For example, focusing only on errors (priority 3 or lower) eliminates the 'debug' messages that clutter the screen. This is crucial when hunting for problems, just as you would when using iotop to find processes freezing your disk.
Real-time visualization
Often, the bug isn't in the static log, but happening right before your eyes. The -f (follow) parameter works just like the classic tail -f. This allows you to watch the log output as the service attempts to restart. It is an indispensable technique when dealing with services that get stuck in loops or stuck resources in failure states that prevent correct environment startup.
Practical procedure for inspecting failures
To diagnose a service that fails to start, follow this logical sequence:
- Check the service status to confirm the failure:
systemctl status service-name.service - Read the last 50 logs of the specific service:
journalctl -u service-name.service -n 50 --no-pager - Watch logs in real-time to capture the error when trying to start:
journalctl -u service-name.service -f
Conclusion
journalctl is not just a log viewer; it is your best ally in critical situations. By mastering time, unit, and priority filters, you drastically reduce the mean time to repair (MTTR) in your Linux systems.
Practice these commands in development environments before you need them in production. Knowing the tool deeply turns the panic of a down service into a methodical and efficient investigation process.