# Init Systems Masterclass: Wer steuert den Kernel?

TL;DR / Management Summary Das Init-System ist der erste Prozess (PID 1) nach dem Booten. Es ist verantwortlich für das Starten aller weiteren Dienste. Während systemd heute der Standard für fast alle großen Distros ist (RHEL, Ubuntu, Arch), bieten minimalistische Alternativen wie OpenRC (Alpine) und runit (Void) massive Vorteile in Bezug auf Transparenz und Ressourcenverbrauch. Ein Senior Admin muss die Konzepte aller drei Systeme kennen, um im RZ und bei Containern die richtige Wahl zu treffen.

# 1. Einführung & Architektur

Die Philosophie der Macht.

• systemd: Ein monolithisches System, das nicht nur Init ist, sondern auch Logging, Netzwerk, DNS und Login verwaltet.
• OpenRC: Eine skriptbasierte Erweiterung des klassischen SysVinit. Nutzt Shell-Skripte für alles.
• runit: Ein extrem minimalistisches System, das Dienste über Verzeichnisse und den Status von Prozessen überwacht.

# Architektur-Vergleich (Mermaid)

graph TD
    subgraph "systemd (Monolith)"
        A[systemd PID 1] --> B[journald]
        A --> C[networkd]
        A --> D[Unit Files]
    end
    subgraph "OpenRC (Modular)"
        E[OpenRC Core] --> F[Shell Scripts]
        E --> G[Standard Syslog]
    end
    subgraph "runit (Minimalist)"
        H[runsvdir] --> I[Service Folder]
        I --> J[Individual run scripts]
    end

# 2. Der Feature-Check

Was können die Systeme?

# 3. Management-Befehle im Vergleich

Die Sprache des Admins.

# 4. Day-2 Operations: Wann nutze ich was?

Die strategische Entscheidung.

# 1. In Containern (Docker/Podman)

Hier ist runit oder ein Wrapper wie Tini (Artikel 214) der Sieger. Ein volles systemd im Container erzeugt zu viel Overhead und Sicherheitsprobleme.

# 2. In minimalistischen VMs (Edge/IoT)

OpenRC ist ideal. Es ist robust, leicht zu debuggen (da alles Shell-Skripte sind) und belegt fast keinen RAM.

# 3. Für Standard-Applikationsserver

Bleiben Sie bei systemd. Die Integration in Monitoring-Tools und die automatische Ressourcen-Limitierung (Cgroups) sind unschlagbar.

# 5. Troubleshooting & “War Stories”

Wenn PID 1 hakt.

# Story 1: “Der hängende Dienst (Zombie)”

Symptom: Ein Prozess ist gestorben, aber systemd zeigt ihn immer noch als active an. Ursache: Der Prozess hat sich in eine Unter-Cgroup verabschiedet, die systemd nicht mehr korrekt trackt (oft bei alten Java-Apps). Lösung: Nutzen Sie systemd-cgls, um die echte Prozess-Hierarchie zu sehen. In runit/OpenRC würde man den Prozess einfach via ps finden und killen.

# Story 2: “Das undurchsichtige Journal”

Symptom: Ein Dienst startet nicht, aber die Fehlermeldung ist im Journal nicht auffindbar. Ursache: systemd puffert Logs. Wenn der Buffer voll ist oder journald selbst hakt, gehen Nachrichten verloren. Lösung: Nutzen Sie bei OpenRC/runit das klassische tail -f. Die Einfachheit von Text-Logs ist in Krisensituationen oft ein Segen.

# 6. Fazit & Empfehlung

• Lernen: Lernen Sie systemd zuerst – es ist der Standard.
• Verstehen: Beschäftigen Sie sich mit OpenRC, um zu verstehen, wie Boot-Skripte wirklich funktionieren.
• Wahl: Nutzen Sie NixOS (Artikel 201) für deklarative Setups, egal welches Init darunter liegt.

# Anhang: Cheatsheet