systemd & journalctl Like a Pro

Write a unit file, follow a single service live, and read boot-to-boot logs with precise filters.

Everyone knows systemctl restart. The senior move is to run your own program as a managed service and to slice the journal down to exactly the lines that matter.

Your app as a unit

Drop a .service file in /etc/systemd/system/ and systemd gives you automatic restart, boot startup, resource limits and centralised logging for free — no nohup, no screen. After editing units, always systemctl daemon-reload.

journalctl beyond -f

  • journalctl -u myapp -f — follow one service live.
  • journalctl -u myapp --since "10 min ago" -p warning — recent warnings and worse.
  • journalctl -b — this boot only; -b -1 is the previous boot (great for diagnosing a crash-reboot).
  • journalctl -u myapp -o json-pretty — structured fields for scripting.
  • journalctl --disk-usage and vacuum-size=200M to reclaim space.

Handy inspection

systemctl status myapp shows the last few log lines and the exact command line; systemctl cat myapp prints the effective unit file including drop-ins; systemd-analyze blame ranks what slowed your boot.

Example

Example · bash
# /etc/systemd/system/myapp.service
#
# [Unit]
# Description=My web app
# After=network.target
#
# [Service]
# ExecStart=/usr/bin/node /srv/myapp/server.js
# Restart=on-failure
# User=www-data
# Environment=NODE_ENV=production
#
# [Install]
# WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myapp        # start now AND on boot

# Follow just this service, warnings and above
journalctl -u myapp -f -p warning

# What did the previous boot log before it rebooted?
journalctl -b -1 -e

# Reclaim journal disk space down to 200 MB
sudo journalctl --vacuum-size=200M

When to use it

  • A DevOps engineer writes a systemd unit with 'Restart=on-failure' and 'RestartSec=5' so the app automatically recovers from crashes without manual intervention.
  • A sysadmin uses 'journalctl -u myapp -b -1' to read logs from the previous boot after a server rebooted unexpectedly overnight.
  • A developer uses 'systemd-analyze blame' to identify slow-starting services delaying boot time on a new server image.

More examples

Write a production-grade unit

A production-ready unit file with dependency ordering, environment file, non-root user, and auto-restart.

Example · bash
# /etc/systemd/system/api.service
[Unit]
Description=API Server
After=network.target postgresql.service

[Service]
User=api
WorkingDirectory=/opt/api
EnvironmentFile=/etc/api/env
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Read structured service logs

Shows three journalctl queries: live follow, previous-boot logs, and filtered by priority and time.

Example · bash
# Follow logs for api service in real time
journalctl -fu api

# Logs from the previous boot (e.g. after a crash)
journalctl -u api -b -1

# Errors only since yesterday
journalctl -u api -p err --since yesterday

Analyse and optimise boot time

Uses systemd-analyze to measure total boot time and blame to rank which services contribute most delay.

Example · bash
# Show total boot time breakdown
systemd-analyze
# Startup finished in 1.2s (kernel) + 8.4s (userspace)

# Rank services by startup time
systemd-analyze blame | head -10
# 4.231s apt-daily.service
# 2.103s snapd.service

Related

linux systemctllinux journalctllinux pro timers

Discussion

  • Be the first to comment on this lesson.