Introduction to Systemd

Introduction to Systemd

Systemd is the init system and service manager used in Ubuntu since 15.04. When the kernel finishes loading, it hands control to PID 1 — and on Ubuntu, that PID 1 is systemd. Everything else: starting services, mounting filesystems, managing cgroups, handling logging, and shutting down cleanly, all flows through systemd. Understanding how systemd works is the foundation of Ubuntu server administration.

What was before systemd

SysVinit (the old way):
  Kernel → /sbin/init (PID 1) → runs /etc/rc.d/rcX.d/ scripts sequentially

  Problems:
  - Scripts run ONE AT A TIME — boot is slow
  - No dependency tracking — wrong start order = broken service
  - No service supervision — if service dies, it stays dead
  - Init scripts were fragile shell scripts, hard to debug

systemd (the new way):
  Kernel → /lib/systemd/systemd (PID 1) → activates units in parallel

  Benefits:
  - Parallel service startup — boot is fast
  - Declarative dependencies — systemd calculates the order
  - Service supervision — automatic restart on failure
  - Structured logging — journald captures everything

Why systemd was created

The core problem with SysVinit was that it was designed for single-CPU machines where serial startup was fine. Modern servers with many cores can start dozens of services simultaneously if dependencies are tracked properly. Additionally, SysVinit had no way to supervise services: if nginx crashed at 3am, it stayed down until someone manually restarted it. Systemd solves both problems: parallel startup based on declared dependencies, and automatic service supervision with configurable restart policies.

The systemd scope

# systemd manages more than just services:
# - Service management (start/stop/restart daemons)
# - Socket activation (start services on-demand)
# - Device management (udev is part of systemd)
# - Mount points (/etc/fstab processed by systemd)
# - Logging (journald collects all service output)
# - Login sessions (systemd-logind)
# - Timers (replacement for cron)
# - Temporary files (systemd-tmpfiles)
# - Boot performance (systemd-analyze)

# Show what systemd is doing:
systemctl --version
systemd-analyze blame    # Time taken by each service at boot

Core systemd components

Units: the building block

# Everything in systemd is a "unit" — a configuration file describing a resource
# Unit types and their file extensions:

# .service  — a process/daemon (nginx, mysql, sshd)
# .socket   — a socket (activated on connection, starts the service)
# .timer    — a scheduled task (replacement for cron)
# .mount    — a mount point (auto-generated from /etc/fstab)
# .target   — a group of units (like runlevels in SysVinit)
# .path     — file/directory watch trigger
# .slice    — a resource control group boundary

# List all units
systemctl list-units

# List all units of a specific type
systemctl list-units --type=service
systemctl list-units --type=timer

# List all unit files (including disabled)
systemctl list-unit-files --type=service | head -20

# Show where unit files are located
systemctl show nginx.service -p FragmentPath

Conclusion

Systemd replaced SysVinit because parallel service startup and built-in service supervision dramatically improve both boot speed and reliability. Every resource systemd manages is described by a unit file. The key tools are systemctl to control services and query state, and journalctl to read logs. Understanding the unit system — especially service, timer, target, and socket units — is the foundation for everything else in systemd administration.