journalctl — systemd unified log

💬 "journalctl command"

journalctl queries service, kernel, and system logs from the systemd journal. It is the starting point for service failure analysis.

Narrow it down by service unit (-u), time range (--since), and priority (-p).

• Concept: Provides a unified view of logs collected by systemd.
• -u unit: View logs only for a specific service (e.g., nginx, myapp).
• -p priority: Filter by severity, such as only showing err and above.
• --since/--until: Specify a time range.

Commonly used options

Three essential command combinations

• journalctl -u nginx -n 100 --no-pager — Check the last 100 lines for nginx
• journalctl -u myapp -f — Follow service logs in real time
• journalctl -p err --since today --no-pager — View only errors that occurred today

💬 "Please give me a hands-on example I can follow step by step"

Here is a step-by-step walkthrough of a common situation on a production server.

Step 1 · Check service status

Check whether it restarted and why it failed.

systemctl status myapp --no-pager

Step 2 · View service logs

Look for exceptions in recent logs.

journalctl -u myapp -n 100 --no-pager

Step 3 · Narrow the time range

Narrow the range based on the time of the incident.

journalctl -u myapp --since '2026-10-18 02:00' --until '2026-10-18 02:10' --no-pager

How to use this in practice

1. The service keeps restarting

Situation — myapp restarts every few minutes.

journalctl -u myapp -n 50 --no-pager | grep -i -E 'error|failed|restart'

Result — The cause, such as a configuration load failure or DB connection error, remains in the logs.

Point — Check the last exit code from status together with the journal logs.

2. Service missing after boot

Situation — A specific service does not start after reboot.

journalctl -b -u myapp --no-pager | head -50

Result — The reasons the service failed to start during this boot appear in order.

Point — Using -b shows only the current boot logs, so they don't get mixed with past logs.

Things to watch out for

• If the journal is not persistently stored, it may be lost on reboot (check Storage=persistent).
• Output can open in a pager and hang in scripts, so use --no-pager for automation.
• If a service is not managed as a unit, it will not appear in journalctl.

Real-world output

This is the result of checking the service logs for the cause of a DB connection failure.

!journalctl command output: service error log

Live production server

Source (HTML): https://games.aidebatehub.com/programs/linux/logs/journalctl.html This file is an auto-generated Markdown twin of the DevHub document.