Skip to content
BytePath
BytePath v0.0.35

Linux Services and systemd Logs

Before you start

Who is this for?

For Linux learners who can use the shell and want to investigate services on a systemd-based distribution.

Prerequisites

  • Linux Essentials
  • Basic command-line navigation

What you'll be able to do

  • Distinguish units from processes
  • Inspect service state
  • Read boot and service logs
  • Diagnose failed units

Practical outcome

Find a service failure's first useful error and select a safe next step.

Linux administrationAvailable

Inspect units, control services safely, and use journal records to troubleshoot failures.

Difficulty
Beginner to Intermediate
Time
65 min
Practice
Investigate a failed service from its status and journal
Assessment
Knowledge check

Many current Linux distributions use systemd to start and supervise services. The service manager coordinates processes and system resources, while the journal collects structured log entries from the kernel and services. Commands and unit names can vary by distribution; check the local manual pages and package documentation.

1. Units and services

Section titled “1. Units and services”

A unit is a systemd object described by a unit file. Common types include .service for services, .socket for sockets, .mount for mount points, .timer for scheduled activation, and .target for groups of units. A service unit describes how a process is started and stopped, its dependencies, and its runtime behavior.

A dependency relationship and ordering relationship are different. Wants= or Requires= describes dependency; After= or Before= describes ordering. For example, After=network-online.target orders a unit after that target, but does not by itself guarantee that networking is healthy or that a remote service is reachable.

2. Inspect before changing

Section titled “2. Inspect before changing”
Terminal window
systemctl status ssh.service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service
systemctl cat ssh.service
systemctl show ssh.service -p ActiveState -p SubState -p Result

The SSH server unit is commonly named ssh.service on Debian-family systems and sshd.service on some others. If you do not know a unit name, list installed service units and consult the package documentation. systemctl status summarizes current state and recent journal messages; systemctl cat displays the unit and any drop-ins.

3. Start, stop, restart, and enable

Section titled “3. Start, stop, restart, and enable”
  • systemctl start name.service starts it now.
  • systemctl stop name.service stops it now.
  • systemctl restart name.service stops and starts it; active connections may be interrupted.
  • systemctl reload name.service asks a service to reload configuration if it supports that operation.
  • systemctl enable name.service configures it to start automatically through its install rules; this does not start it now.
  • systemctl enable --now name.service enables it and starts it now.
  • systemctl disable name.service removes its automatic enablement; it does not necessarily stop a running service.

Changing service state normally requires administrator privileges. Do not restart a production service just to see what happens. Confirm the affected service, maintenance window, and rollback route first.

4. Read the journal with journalctl

Section titled “4. Read the journal with journalctl”

journalctl queries the systemd journal. Useful filters include:

Terminal window
journalctl -b                         # current boot
journalctl -b -1                      # previous boot, if retained
journalctl -u ssh.service --since today
journalctl -u ssh.service -p warning
journalctl -u ssh.service -n 50 --no-pager
journalctl --list-boots

-b selects a boot; -u selects a unit; --since narrows time; -p filters by priority; and -n limits the number of entries. Journal retention and whether earlier boots are available depend on local configuration. Some applications also write files under /var/log instead of, or in addition to, the journal.

5. A repeatable failed-service investigation

Section titled “5. A repeatable failed-service investigation”
  1. Record the host, service, time, and user-visible symptom.
  2. Run systemctl status name.service and note the unit state and first error.
  3. Read focused messages with journalctl -b -u name.service --since '30 minutes ago'.
  4. Inspect the unit with systemctl cat and verify the executable, config path, and dependencies.
  5. Check permissions, free space, and whether the configured port is already in use.
  6. Validate configuration with the service’s documented check command, if available.
  7. Make one approved change, start or reload the service as appropriate, then recheck status and logs.

A nonzero process exit is a clue, not a complete diagnosis. Logs may include secrets, personal data, or tokens; handle and share them according to local policy.

6. Unit-file changes

Section titled “6. Unit-file changes”

Prefer a documented drop-in rather than editing a vendor unit under /usr/lib/systemd/system or /lib/systemd/system, because package updates may replace those files. systemctl edit name.service creates a drop-in. After changing unit metadata, run systemctl daemon-reload so systemd rereads unit files, then inspect the result with systemctl cat before restarting.

Use the smallest necessary privilege and avoid copying a unit from an unrelated distribution. Unit options and service behavior can differ by systemd version; the systemd manual and local man systemd.unit are authoritative for the installed system.

Practical exercise

Section titled “Practical exercise”

In a disposable VM, inspect a harmless service such as cron.service or crond.service (whichever exists). Find its unit file, view its current status, and query its current-boot logs. Do not stop or restart it. Write down which command showed state and which command showed event history.