Linux Tutorial / Understand systemd Services, Boot, and Logs

On a Linux system that uses systemd, boot proceeds from firmware and bootloader to the kernel; then systemd activates services and other units. To investigate a service, use systemctl to check both its current state and its boot-time enablement, and use journalctl to read logs from the same boot. Being active now and being enabled for boot are different conditions.

Understand the main stages of boot

A typical PC or server starts with firmware initializing hardware and locating a bootloader. The bootloader loads the kernel and required early environment. The kernel prepares devices, memory, and process execution, after which an initialization system manages userspace services. This lesson applies where systemd is PID 1. A container or distribution using another init system may require different commands and explanations.

ps -p 1 -o pid,comm,args
systemctl get-default

Use COMMAND or ARGS in the first result to check whether PID 1 is systemd. It may differ in a container or specialized environment. The second command shows the default target. For example, multi-user.target commonly represents a multiuser non-graphical goal; graphical.target can represent a graphical goal. A target groups units. It does not mean all services start one after another in a single sequence.

Understand systemd units and dependencies

systemd represents managed objects as units. A .service unit handles a service; a .target groups units into a goal; a .socket can provide socket-based activation; and a .timer schedules an action. A service's package and unit must actually be installed. Do not guess a unit name and start or stop it on a production machine.

Boot ordering follows unit dependencies and ordering rules, not a simple numeric order. A rule that starts one unit after another does not automatically make the first a required dependency. Some units run in parallel, so the order of a displayed list alone cannot establish the cause of slow startup.

systemctl list-units --type=service --state=running
systemctl --failed

The first command lists loaded running service units; the second lists units in a failed state. An empty failed list does not prove that an application is responding correctly. Its endpoint, port, or own logs may also need checking.

Separate current state from boot enablement

active concerns whether a unit is active now. enabled normally means an installation link has been created so that it can start with a target at boot. A service can be active but disabled, or enabled but currently failed. A static unit may lack an install rule for direct enablement yet still run because another unit requires or activates it.

NAME.service in the table is a placeholder: replace it with a unit that exists on your system. Stopping a critical unit such as the SSH service used for remote access can disconnect you. Check impact and a recovery route before changing any production service.

Inspect a service with read-only commands

systemd-journald.service is common on systemd systems, although a minimal or specialized image may behave differently. These commands only inspect state.

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status may show load information, current state, processes, and recent journal entries. is-active can report active, inactive, or failed and can return a nonzero exit status when inactive. is-enabled can report enabled, disabled, or static, among other results. Do not treat static as an error by itself.

Commands to know before changing a service

When a change is warranted, start and stop affect the current state, while enable and disable affect automatic activation. restart stops and starts a service and can interrupt connections or work. reload asks a service to reread configuration only if it supports that operation; the effect is service-specific. enable --now requests both enablement and an immediate start.

After creating or editing a unit file, daemon-reload may be needed so systemd rereads unit definitions. That differs from restart, which restarts an application process, and a service's own reload, which may reread application configuration. Plan backups and a maintenance window before changing production unit or application configuration.

Read logs for the current boot with journalctl

The systemd journal can collect messages from services, the kernel, and other sources. -b selects the current boot, -u selects a unit, and -n 30 requests the most recent 30 entries. Without appropriate permissions, you may see only some messages; an authorized administrator can inspect the rest.

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

The first command shows recent entries for that unit during this boot. The second shows recent entries at warning priority or higher. One warning is not necessarily the cause of a failure; consider its time and surrounding messages. If --list-boots shows no earlier boot, journal retention or storage policy may mean its logs are unavailable. Check that an earlier boot is recorded before trying to diagnose it.

A sequence for diagnosing a service that will not start

1. Confirm the exact unit name and whether its package is installed. Do not manipulate a similarly named unit by guesswork.
2. Use systemctl status to check the load state, current state, failure summary, and recent messages.
3. Read more context from the same boot with journalctl -b -u. Look for evidence of a configuration error, permissions, a port conflict, or a failed dependency.
4. Inspect the relevant configuration, resources, and dependencies; make a backup before changing them. Do not broadly weaken permissions based on one log line.
5. After fixing the cause, perform only the needed action at an acceptable time, then verify is-active and the application's real response.

For slow boot, systemd-analyze critical-chain can help reveal an important startup path. A long individual duration in systemd-analyze blame does not, by itself, prove that unit delayed the entire boot. Parallel execution and dependencies matter.

Official references

The systemctl(1) manual covers status and changes to units. The journalctl(1) manual documents boot, unit, and priority filters. The systemd.unit(5) manual describes units and their dependency relationships.