Privacy Policy
© 2025 linux101.dev

What is systemd?

Think of systemd as the system's "manager" that the kernel starts first. It runs as PID 1 (the very first user program) and is responsible for starting other programs, mounting filesystems, keeping services running, and stopping them on shutdown.

When does it start?

Right after the kernel finishes starting, systemd is started as the first user-space process. You can check this on your machine: 

ps -p 1 -o pid,comm

If you see "systemd" here, that means systemd is PID 1.

What does systemd do? (simple)

  • Start programs: it launches services like networking, ssh, and databases when your computer boots.
  • Mount filesystems: it converts /etc/fstab entries into mount units and mounts drives during boot.
  • Keep services running: if a service dies, systemd can restart it automatically.
  • Order boot steps: it knows which services must start first and which can start later or in parallel.
  • Shut down cleanly: it stops services in the right order on shutdown or reboot.

What is a "unit"?

A unit is a small configuration file that tells systemd how to manage something. Common types:

  • .service — a running program (example: sshd.service).
  • .mount — a mounted filesystem.
  • .timer — schedules a unit to run at a certain time or interval (like a lightweight cron).

Systemd treats services, mounts and timers the same way: as unit files it can start, stop, and monitor.

Essential services systemd commonly runs

Distributions differ, but you will commonly see:

  • systemd-journald — collects logs from the kernel and services (readable with journalctl).
  • systemd-udevd — manages device events and /dev entries when hardware appears or is removed.
  • dbus.service — the message bus used for inter-process communication.
  • systemd-logind — handles user logins, seats and sessions (console management).
  • Network services — either systemd-networkd or distro tools like NetworkManager to configure networking.
  • sshd.service — (if installed) allows remote shell access via SSH.
  • systemd-resolved — DNS name resolution on some systems.

Use systemctl status some.service to inspect any of these and see their recent logs.

Where unit files live — /etc/systemd/system/ and friends

Unit files come from two common places:

  • /lib/systemd/system/ (or /usr/lib/systemd/system) — unit files provided by the distribution or packages.
  • /etc/systemd/system/ — unit files added or customized by the system administrator. Files here override the distribution-provided ones.

List unit files defined locally

ls -l /etc/systemd/system/

Shows unit files and symlinks created on your system (local overrides and enabled units).

Check a unit's file and where it comes from

systemctl cat ssh.service

Shows the unit's content and any drop-in files; helps find whether it comes from /lib or /etc.

Timer units — what they are and where they are defined

Timer units are unit files with the .timer suffix. They schedule when a corresponding .service should run — conceptually similar to cron but managed by systemd.

Common timer settings you will see inside a .timer:

  • OnCalendar= — run on calendar events (example: daily, Mon *:00).
  • OnBootSec= — run a given time after boot.
  • OnUnitActiveSec= — run a given interval after the service last finished.
  • Persistent=true — if true, run missed jobs that should have run while the machine was off.

Timer unit files live in the same systemd unit directories as other units: /lib/systemd/system (or /usr/lib/systemd/system) for distribution-installed timers, and /etc/systemd/system for administrator-installed or overridden timers. Drop-in snippets may appear in directories like /etc/systemd/system/foo.timer.d/.

List scheduled timers

systemctl list-timers --all

Shows active and inactive timers, next/last run times, and the service they trigger.

Inspect a timer unit and its source

systemctl cat foo.timer

Shows the timer file and any drop-ins; use systemctl status foo.timer to see next/last trigger times.

Where do system logs go? (journald)

systemd's logging service is called journald. It collects messages from the kernel and all services.

  • If persistent logging is enabled, logs are stored on disk under /var/log/journal and survive reboots.
  • If persistent logging is not enabled, logs are kept in memory under /run/log/journal and are lost after a reboot.

View logs from current boot

journalctl -b

View recent messages for a service (example: ssh)

journalctl -u ssh.service --since "1 hour ago"

/etc/fstab and mounts — how systemd handles them

systemd uses systemd-fstab-generator early in boot to turn /etc/fstab entries into .mount unit files. Those mount units are then started and tracked like any other unit, which gives mounts the same ordering and dependency guarantees as services.

See mounts known to systemd

systemctl list-units --type=mount

Look at your fstab file

cat /etc/fstab

Quick real-world examples

  • Check if a service is running: systemctl status ssh.service.
  • Start/stop a service right now: sudo systemctl start foo.service / sudo systemctl stop foo.service.
  • Enable a service to start at boot: sudo systemctl enable foo.service.

Use the example commands above on your machine to explore units, mounts and logs interactively.