Many times, you might not know something is wrong with your computer until it starts to directly affect your use of the computer. But when it does happen, it's good to know what's causing it, and Linux users have a very powerful command at their disposal that makes it much easier to troubleshoot their problems.

Whether it's a critical error crashing specific apps, some device not working, or just odd behavior, here's how Linux can help you get to the bottom of it.

See every error affecting your PC

It's that easy

I didn't think it would be possible to see a rundown of every error affecting my PC in one go, but there's a very simple command that lets you see every critical error that's affected your PC since the last boot. If you're curious, you only need to enter this in your terminal:

journalctl -p 3 -b

Of course, this may output a pretty long line of text. If you want to make it a bit easier to go through the list of errors, you can write the output of the command to a text file so you can analyze it more carefully later. That would be something like this:

journalctl -p 3 -b > path/to/file.txt

You can run this command immediately after boot to detect any issues that might be happening at startup and affecting your entire experience, or you can wait and run it later, particularly after you experience any specific issue you'd like to track down. When I first ran the command, I had left the computer on overnight, and the resulting file had over 500 lines. Running it right after boot yielded just around 20, so that made it easier to parse.

You can use it in other ways

Narrow down your results

Of course, if you're trying to spot errors a long time after boot or there's just a lot going on in your PC, exporting a log of every single error may get overwhelming quickly. But the journalctl command is actually very versatile, and you can tweak this command to get specific results. For example, if you know an error you're looking for is related to a specific program or feature, you can use pipes and combine it with the grep command to search for specific errors. For example, you might want to look for issues with Bluetooth, so you can use this command:

journalctl -p 3 -b | grep -E "bluetooth|hci0"

You can also define the priority level of the messages you're highlighting, which is what the -p argument is for. Using the value 3 here means we're selecting the three highest priority levels for system messages. Using 1 would get you the highest priority level messages only, while going down to 4 or 5 would start including things like warnings or just information messages.

And if you're curious, the -b argument is what limits the command to just the messages shown since the last boot process. You can remove that to see all the messages since your operating system was installed.

Some work is still required

You need to know what you're looking for

As useful as this command is, it's obviously not something you need to run if you're not noticing any problems, and you might not be able to find any specific issues just by looking at it. For example, when I ran this command immediately after boot, there were a couple of things that stood out. One of them was this line:

archlinux bluetoothd[726]: Failed to set default system config for hci0

This suggested Bluetooth devices could have some issues, but I actually never use Bluetooth devices with my laptop, so I had to test it out. After turning Bluetooth on and connecting my headphones, though, everything worked fine. Likewise, I got a series of errors about "touchpad jumps" related Kwin (the Wayland compositor in KDE Plasma), but I've also never noticed any issues with my touchpad.

It serves to show that if you go looking for errors without noticing anything wrong in the first place, you may end up just wasting a lot of time looking at non-issues.

However, if you do have any problems, this command can help you find what could be causing it. I have a strange issue when using OBS Studio in that, whenever I close the app, it just tells me that it crashed and then closes. That error shows up in the logs generated by this command, too, and it gives me a long list of error codes that helped cause the problem. It looks something like this:

I can use these error codes to look for what might be the cause behind the crashes, and thus fix them or report them to the developers of the software.

Learn to fix your Linux problems

Half of the challenge with fixing a software problem is knowing what's wrong in the first place, and the journalctl command is an extremely helpful way to see everything that might be wrong with your system. Not everything you see will be worthy of attention, but when you know what to look for, this command is powerful, and it could give you the tools to fix the problems you're having.