Learn to read, filter and act on service logs to find what breaks and why. 22.01.2026 | reading time: 3 min When a service fails, the administrator needs precise facts fast; journalctl reads systemd's binary journal and lets him filter by unit, priority, boot and time to find the root cause. Hands-on example A typical scenario: nginx refuses to start and systemctl shows a failure; run a quick status check then inspect recent logs for that unit: ```sudo systemctl status nginx.service ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2026-01-22 12:34:56 UTC; 2s ago Process: 1234 ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' (code=exited, status=1/FAILURE) Jan 22 12:34:56 host systemd[1]: nginx.service: Failed with result 'exit-code'. ``` Now pull the journal for that unit and read the error lines at boot time: ```sudo journalctl -u nginx.service -b --no-pager Jan 22 12:34:55 host nginx[1234]: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) Jan 22 12:34:55 host nginx[1234]: nginx: configuration file /etc/nginx/nginx.conf test failed Jan 22 12:34:56 host systemd[1]: nginx.service: Main process exited, code=exited, status=1/FAILURE ``` Filters that speed diagnosis Start with simple filters and add complexity only when needed; use `journalctl -u <unit>` to scope to a unit, `-b` to limit to the current boot, `-n 50` to show recent lines and `-f` to follow live, and combine `-p` with a priority name or number to see only errors and above such as `journalctl -u sshd -p err`. Viewing formats and exports journalctl supports multiple output formats and exports, so he can request machine-readable JSON with `-o json` for tooling, extract a compact message stream with `-o cat` for piping to grep, or export a slice with `--since` and `--until` to share with colleagues or attach to a bug report. Integrations and fallbacks systemctl status gives a quick summary paired with live `journalctl -f` for debugging, while traditional syslog daemons such as rsyslog can forward or persist messages outside the journal and tools like logrotate still manage archived plain-text logs on some systems. Wrap-up and next steps Reading and filtering service logs is a daily task for any administrator; master the key journalctl switches and he will solve many failures faster, and for deeper, exam-focused study consider training pathways and certifications such as CompTIA Linux+ or LPIC-1 with intensive preparation at bitsandbytes.academy. Join Bits & Bytes Academy First class LINUX exam preparation. troubleshooting boot-process processes infrastructure utilities