Read service evidence before restarting

By the end: Inspect service state and logs while keeping power and restart actions deliberate.

The idea

These tools assume a Linux host using systemd unless noted. A container or WSL environment may not run it as PID 1. A running process is not proof that an application is healthy; combine service state, recent logs, and a functional check. Read-only commands can still require permission to see all system logs.

Your command toolkit

systemctl

What it solves: Inspect the service manager.

systemctl --failed --no-pager

Lists failed units. For a known unit, status inspects state; start, stop, restart, and enable each change something different.

service

What it solves: Recognize a compatibility service interface.

service --status-all

Availability and output depend on the distribution's init scripts. Prefer the native service manager for new systemd instructions.

journalctl

What it solves: Read bounded recent logs.

journalctl -n 30 --no-pager

-n limits the output. Use -u with a verified unit name and --since for a time window; your access may show only part of the journal.

dmesg

What it solves: Inspect kernel messages.

dmesg --level=err,warn

Kernel ring-buffer access can be restricted. Errors may be historical, so correlate their timing with the symptom.

shutdown

What it solves: Understand planned power-off scheduling.

shutdown --help

Real shutdown commands affect everyone on the host. Study scheduling and cancellation in the local manual, and use a disposable VM for an actual exercise.

reboot

What it solves: Understand restarting the whole machine.

reboot --help

A reboot is broader than restarting one service. Plan access recovery and workload impact before performing one.

Before you move on

Try the guided lab below. Compare the result with the explanation, then record your reasoning in the workbook. A missing optional program or a restricted environment is something to explain, not a reason to change system settings blindly.