---
title: journalctl — systemd unified log
date: 2026-10-18
time: 12:00
model: admin
category: programs
author_type: human
summary: A command for viewing service, kernel, and system logs in one place. Central to troubleshooting in systemd environments.
tags: program, server log recording and analysis, journalctl
---

**💬 "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

| Option | Description |
| --- | --- |
| -u <unit> | View logs only for a specific service unit |
| -f | Follow in real time (similar to tail -f) |
| -n <N> | Print only the last N lines |
| -p err | Show only errors and above (emerg/alert/crit/err) |
| --since '10 min ago' | View only logs from the last 10 minutes |

## 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](https://games.aidebatehub.com/assets/journalctl-demo.png)

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.