Managing Linux Services and Logs with systemd and journalctl

On many modern Linux distributions, systemd starts the system, manages services, and collects logs. Understanding systemctl and journalctl helps you determine whether a service is running, why it stopped, and what happened before a failure.

What is a systemd unit?

Systemd manages units such as .service, .socket, .timer, and .mount. Service units are the most familiar, but the complete unit name is useful when several activation mechanisms are involved.

Check service status

systemctl status nginx.service
systemctl is-active nginx.service
systemctl is-enabled nginx.service
systemctl list-units --type=service --state=failed

Active describes current runtime state, while enabled describes whether the unit participates in startup. These are independent states.

Start, stop, restart, and reload

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx

A restart may interrupt requests. Reload asks a service to apply new configuration without a full stop, but only works when the service supports it.

Enable and start

sudo systemctl enable nginx
sudo systemctl enable --now nginx
sudo systemctl disable nginx

Before enabling a new service, validate its configuration, listening ports, and access requirements.

Read logs with journalctl

journalctl -u nginx.service
journalctl -u nginx.service -n 100
journalctl -u nginx.service -f
journalctl -u nginx.service --since "1 hour ago"

Filter by unit, limit output, follow new events, and narrow the time range around an incident.

Filter by priority and boot

journalctl -p warning..alert
journalctl -b
journalctl -b -1
journalctl --disk-usage

The previous boot is particularly useful when a machine restarted after a failure.

Troubleshoot a failed service

1. Read the short status and exit code.
2. Inspect the unit journal for the current boot.
3. Run the application's configuration test.
4. Verify user, permissions, environment, ports, and dependencies.
5. Reload systemd after unit changes, then restart and monitor.

Create a simple service

[Unit]
Description=Example worker
After=network-online.target

[Service]
Type=simple
User=app
WorkingDirectory=/srv/example
ExecStart=/usr/bin/php /srv/example/artisan queue:work
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now example-worker
systemctl status example-worker

Use overrides for packaged units

sudo systemctl edit example-worker.service
systemctl cat example-worker.service

Drop-in overrides survive package updates more cleanly than editing vendor files. Keep secrets out of broadly readable unit definitions.

Control journal storage

journalctl --disk-usage
sudo journalctl --vacuum-time=14d
sudo journalctl --vacuum-size=500M

Choose retention according to investigation needs and available storage instead of deleting logs reactively during an incident.

References

• systemd: systemctl
• systemd: journalctl
• systemd.service