When your Linux system is generating thousands of log entries every minute, finding information about a specific service can feel like searching for a needle in a haystack. That's where journalctl's powerful filtering capabilities come to the rescue!
To filter journalctl logs by a specific service, use the service name in the following manner:
journalctl -u servicename
The -u flag (short for "unit") is your primary tool for filtering logs by service. It tells journalctl to show only entries related to a specific systemd unit.
journalctl -u mysql
The above command shows mysql log entries:
Jun 23 07:51:39 ghost-learnubuntu systemd[1]: Starting MySQL Community Server...
Jun 23 07:51:47 ghost-learnubuntu systemd[1]: Started MySQL Community Server.
Jun 23 07:56:53 ghost-learnubuntu systemd[1]: Stopping MySQL Community Server...
Jun 23 07:56:56 ghost-learnubuntu systemd[1]: mysql.service: Succeeded.
Jun 23 07:56:56 ghost-learnubuntu systemd[1]: Stopped MySQL Community Server.
Jun 23 07:56:56 ghost-learnubuntu systemd[1]: Starting MySQL Community Server...
Here are some other real-world examples of extracting logs of certain services:
# View Apache logs
journalctl -u apache2
# View SSH daemon logs
journalctl -u ssh
# View Docker logs
journalctl -u docker
Finding the right service name
Before you can filter, you need to know the exact service name. One way would to be to list all systemd services:
systemctl list-units --type=service
This shows all currently loaded services with their exact names.
UNIT LOAD ACTIVE SUB DESCRIPTION
accounts-daemon.service loaded active running Accounts Service
acpid.service loaded active running ACPI event daemon
alsa-restore.service loaded active exited Save/Restore Sound Card State
apparmor.service loaded active exited Load AppArmor profiles
apport.service loaded active exited LSB: automatic crash report generationAs you can see above, there are five services visible. You may omit the .service part of the unit name. Instead of apport.service, you could just use apport. However, some services may have both .service and .socket units.
The problem here is that you'll have hundreds of services running. Scrolling through all of them is a waste of time. Make use of the good old grep command.
For example, find services containing "ssh" in their name.
systemctl list-units --type=service | grep ssh
This is because some distributions use sshd for ssh service name. So getting the correct name by filtering helps to get the ssh logs correctly.
More tips on filtering journal logs by services
You learned to show journalctl logs for a specific service. But there could still be way too much or perhaps way too little logs. Let's see more ways of expanding or narrowing down your log filtering by services.
Multiple services at once
Monitor multiple services simultaneously - perfect for troubleshooting interconnected applications!
journalctl -u nginx -u mysql -u redis
Service patterns with wildcards
View logs from all services starting with "docker". Note the quotes around the pattern!
journalctl -u 'docker*'
Service logs with context
By default, you get all the logs of the specific service. Reduce the noise by showing the last 50 log entries only.
journalctl -u servicename -n 50
Reverse chronological order
Show newest entries first - great for finding recent issues quickly.
journalctl -u servicename -r
Combine with time filtering
Get journal logs for a specific date range instead of displaying all the possible logs for the service,
journalctl -u servicename --since "2024-01-01" --until "2024-01-02"
Add more time frames as needed:
--since "2023-01-01"--since "yesterday"--since "10 minutes ago"--since "1 hour ago"
Priority-based service filtering
Show only error-level messages from a service.
journalctl -u servicename -p err
You can use other priority levels include:
debug(7)info(6)notice(5)warning(4)err(3)crit(2)alert(1)emerg(0)
Logs from most recent service boot
By defaulShow only logs from the current boot session.
journalctl -u servicename -b
Follow service logs in real-time
Watch journalctl logs as they happen - perfect for live troubleshooting!
journalctl -u servicename -f
📋Summary
| Option | Syntax | Description | Example |
|---|---|---|---|
| Basic Service Filter | -u servicename |
Show logs for specific service | journalctl -u mysql |
| Multiple Services | -u service1 -u service2 |
Monitor multiple services simultaneously | journalctl -u nginx -u mysql -u redis |
| Service Pattern | -u 'pattern*' |
View logs from services matching pattern | journalctl -u 'docker*' |
| Last N Lines | -u servicename -n N |
Show last N log entries for service | journalctl -u servicename -n 50 |
| Reverse Order | -u servicename -r |
Show newest entries first | journalctl -u servicename -r |
| Time Range | -u servicename --since "start" --until "end" |
Get logs for specific date range | journalctl -u servicename --since "2024-01-01" --until "2024-01-02" |
| Time Since | -u servicename --since "time" |
Show logs since specific time | journalctl -u servicename --since "yesterday" |
| Priority Filter | -u servicename -p priority |
Show only specific priority level messages | journalctl -u servicename -p err |
| Current Boot | -u servicename -b |
Show logs from current boot session only | journalctl -u servicename -b |
| Follow Real-time | -u servicename -f |
Watch logs in real-time as they happen | journalctl -u servicename -f |
Wrapping Up
Filtering journalctl logs by service is an essential skill for Linux system administration. It transforms overwhelming log output into focused, actionable information. Start with the basic -u flag, then gradually incorporate time filters, priority levels, and output formatting as your needs become more sophisticated.
Remember: the key to effective service log analysis is knowing your service names, understanding the relationships between services, and using the right combination of filters to find exactly what you're looking for.
Happy service debugging!
