How to troubleshoot Linux app startup issues with the journalctl command
Something rarely goes wrong with Linux, but that doesn’t mean the operating system is immune to problems. Every once in a while, I’ll install a new service or app and then go to start it with the command:
sudo systemctl start NAME
Where NAME is the name of the app or service.
Also: The first 5 Linux commands every new user should learn
There have been instances where the service refuses to start or run properly. When that happens, where do you turn? You could always check log files (usually the best place to start) or turn to another command that is a companion to systemctl. That command is journalctl.
The journalctl command queries the systemd journal and lists the contents of a journal that could include insights into why a particular app or service isn’t running properly. Often, when you attempt to start a service with systemctl, if the service doesn’t start properly (or at all), you’ll see a suggestion in the output to use the journalctl command to find out what has happened.
Let me show you how to use this command, so you don’t have to be in the dark as to why things aren’t going as planned.
How to use journalctl
What you’ll need: The only thing you’ll need for this task is a Linux distribution that uses systemd, which is most of the major distributions.
The first thing you should try is running journalctl without any options, which is simple:
journalctl
What you will see is the entire output of the systemd journal. From that output, you might find information to help you troubleshoot your problem.
When I ran the command, there were only 41 lines of output. I’ve seen instances where there were hundreds of lines in the output, which made using the command without arguments or options a bit unhelpful.
Also: 10 Linux apps I install on every new machine (and why you should, too)
Fortunately, you can filter out a lot of that noise.
For instance, SSH is having problems starting. To troubleshoot this issue, you could run the command:
systemctl -u ssh
In this case, -u stands for unit, or a specific systemd unit (think “service”).
Also: How to create system restore points on Linux with Timeshift – and why you should
The output of the above command might look something like this:
Jan 12 09:55:42 pop-os systemd[1]: Starting OpenBSD Secure Shell server…
Jan 12 09:55:42 pop-os sshd[3424]: Server listening on 0.0.0.0 port 22.
Jan 12 09:55:42 pop-os sshd[3424]: Server listening on :: port 22.
Jan 12 09:55:42 pop-os systemd[1]: Started OpenBSD Secure Shell server.
Jan 15 09:39:26 pop-os sshd[659190]: Invalid user jackwallen from 192.168.1.77 port 55040
Jan 15 09:39:29 pop-os sshd[659190]: pam_unix(sshd:auth): check pass; user unknown
Jan 15 09:39:29 pop-os sshd[659190]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.77
Jan 15 09:39:31 pop-os sshd[659190]: Failed password for invalid user jackwallen from 192.168.1.77 port 55040 ssh2
Jan 15 09:39:33 pop-os sshd[659190]: Connection closed by invalid user jackwallen 192.168.1.77 port 55040 [preauth]
Jan 15 09:39:39 pop-os sshd[659232]: Accepted password for jack from 192.168.1.77 port 55049 ssh2
Jan 15 09:39:39 pop-os sshd[659232]: pam_unix(sshd:session): session opened for user jack(uid=1000) by (uid=0)
As you can see, in my case, SSH is running as expected, but there was a failed attempt at logging in (which was because I forgot to add a valid username when logging in from my iMac).
There’s an even better way to troubleshoot a service with journalctl. Let’s say SSH is running but having trouble accepting connections (or just about any other issue that could happen). You can “tail” the output (which prints out real-time information as it happens), like so:
journaltcl -xefu ssh
This command will not only tell you the startup and running status of the service but will list the most recent entries logged to the journal for that service. To close, use the Ctrl+c keyboard shortcut. For those who want to know, here’s an explanation of the options:
- x – add an explanation to the log lines from the message catalog
- e – immediately jump to the end of the journal inside the implied pager tool
- f – follow (continuously print new entries as they are logged)
- u – unit (as explained above)
It’s also possible to view a specific time range with journalctl. Say you want to view only entries logged starting Jan. 20 at 10:00 AM. The command would be:
journalctl –since “2025-01-20 10:00:00”
You would see every entry logged from 10:00 AM to the current time.
Also: How to keep Linux optimized (and save time) with Stacer
You could make that range even more specific. Say you want to view entries logged from 10:00 AM to 10:10 AM. The command would be:
journalctl –since “2025-01-20 10:00:00” –until “2025-01-20 10:05:00”
And that, my friends, is how you can use journalctl to troubleshoot app startup issues on Linux.