Service log review on Linux exposes start failures, crashes, and dependency errors that are not visible in status summaries. Reading the journal around the time of an incident helps isolate whether the failure is internal to the service or triggered by a dependency or environment change.
On systemd systems, systemd-journald collects logs from services and stores them in the journal. journalctl queries that journal, and filtering by unit with --unit (or -u) shows messages for a single service while keeping timestamps, priorities, and process context.
Access to complete logs often requires sudo, and older entries may only be available when persistent storage is enabled under /var/log/journal. Noisy units can produce a lot of output, so prefer a line limit, a time window, or a priority filter to focus on the most relevant messages.
Steps to view Linux service logs with journalctl:
- Show the most recent log lines for the service unit.
$ sudo journalctl -u example.service --no-pager --lines=10 Jan 10 07:30:16 host.example.net systemd[1]: Stopped example.service - Example API. Jan 10 07:30:16 host.example.net systemd[1]: Started example.service - Example API. Jan 10 07:30:40 host.example.net systemd[1]: Stopping example.service - Example API... Jan 10 07:30:40 host.example.net systemd[1]: example.service: Deactivated successfully. Jan 10 07:30:40 host.example.net systemd[1]: Stopped example.service - Example API. Jan 10 07:30:40 host.example.net systemd[1]: Started example.service - Example API. Jan 10 07:31:03 host.example.net systemd[1]: Stopping example.service - Example API... Jan 10 07:31:03 host.example.net systemd[1]: example.service: Deactivated successfully. Jan 10 07:31:03 host.example.net systemd[1]: Stopped example.service - Example API. Jan 10 07:31:03 host.example.net systemd[1]: Started example.service - Example API.
Replace example.service with the systemd unit name, with or without the .service suffix.
- Show recent log entries for the service unit.
$ sudo journalctl -u example.service --since "1 hour ago" Jan 10 07:30:40 host.example.net systemd[1]: Stopping example.service - Example API... Jan 10 07:30:40 host.example.net systemd[1]: example.service: Deactivated successfully. Jan 10 07:30:40 host.example.net systemd[1]: Stopped example.service - Example API. Jan 10 07:31:03 host.example.net systemd[1]: Started example.service - Example API. Jan 10 07:31:04 host.example.net example-api[153340]: 127.0.0.1 - - [10/Jan/2026 07:31:04] "GET / HTTP/1.0" 200 - ##### snipped #####
Increase the time range or use an absolute timestamp when older entries are needed.
- Stream the service log while reproducing the issue.
$ timeout 2 sudo journalctl -u example.service --follow Jan 10 07:31:03 host.example.net systemd[1]: Started example.service - Example API. Jan 10 07:31:04 host.example.net example-api[153340]: 127.0.0.1 - - [10/Jan/2026 07:31:04] "GET / HTTP/1.0" 200 -
Stop streaming with Ctrl+C.
- Filter to error-level messages for quick triage.
$ sudo journalctl -u example.service --priority=err..alert -- No entries --
Priority filtering reduces noise by showing only high-severity entries.
- Show service log entries from the previous boot.
$ sudo journalctl -u example.service --boot=-1 -- No entries --
Previous-boot logs require a persistent journal under /var/log/journal.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
