Thema: systemd
-
cgroups v2 auf dem Host: Modus prüfen und Ressourcenlimits pro Unit auslesen
Moderne Container-Runtimes und systemd setzen für Speicher- und CPU-Limits auf cgroups v2 (die vereinheitlichte Hierarchie). Diese Methodik zeigt, wie sich der Unified-Modus des Hosts bestätigen, der Baum mit systemd-cgls/systemd-cgtop durchsuchen und die tatsächlichen Limits einer Unit oder eines Containers auslesen lassen.
-
journald-Weiterleitung und zentrale Log-Sammlung: ForwardToSyslog, systemd-journal-upload/-remote und Rate Limits
journald kann seine Einträge mit ForwardToSyslog= an einen lokalen Syslog-Daemon übergeben oder per systemd-journal-upload direkt über HTTPS an einen systemd-journal-remote-Listener senden, der eigene Journal-Dateien schreibt. Beide Wege unterliegen dem journald-eigenen Rate Limiting pro Dienst: Nach Überschreiten des Burst-Schwellwerts verwirft es überzählige Meldungen und protokolliert nur deren Anzahl.
-
systemd-Timer als Cron-Ersatz: OnCalendar, Persistent= und RandomizedDelaySec
Eine systemd-.timer-Unit zusammen mit einem oneshot-.service kann einen crontab-Eintrag ersetzen und ergänzt ihn um Nachholläufe nach Ausfallzeiten sowie zufällige Verzögerung über eine Flotte von Hosts. Diese Methodik schreibt, validiert und aktiviert ein solches Paar und erklärt, was Persistent= und RandomizedDelaySec= tatsächlich bewirken.
-
„Too many open files“ (EMFILE) und das Limit für Dateideskriptoren
EMFILE, gemeldet als „Too many open files“, bedeutet, dass ein Prozess sein eigenes Limit für gleichzeitig offene Dateideskriptoren erreicht hat (dokumentiert als RLIMIT_NOFILE). Der Artikel zeigt, wie sich ein echtes Deskriptor-Leck von einem schlicht zu niedrigen Limit unterscheiden lässt und wie sich das Limit in der Shell, in PAM und in der systemd-Unit erhöhen lässt.
-
.env-Dateien im Vergleich: Quoting, export, mehrzeilige Werte und Expansion in fünf Loadern
Docker Compose, docker run --env-file, python-dotenv, Node-dotenv, systemd-EnvironmentFile und das Sourcen der Datei in einer Shell akzeptieren scheinbar identische Dateien, verhalten sich aber bei Quoting, dem Schlüsselwort export, mehrzeiligen Werten und der Expansion von ${VAR} unterschiedlich.
-
Podman-Container mit Quadlet als systemd-Dienste betreiben
Quadlet erlaubt es systemd, Podman-Container direkt aus deklarativen .container-Unit-Dateien zu verwalten, und ersetzt den veralteten Workflow mit podman generate systemd. Die Methodik behandelt Dateiorte für System- und Benutzerdienste, die Aktivierung und das Label für automatische Updates.
-
Die Linux-Boot-Kette für die Fehlersuche: Firmware, Boot Loader, Kernel, initramfs und systemd
Ein Linux-Boot durchläuft Firmware, Boot Loader, Kernel, initramfs und schliesslich den System-Manager; jede Stufe übergibt die Kontrolle an die nächste. Wer weiss, was jede Stufe leistet und wo sie protokolliert, kann einen fehlgeschlagenen Boot auf eine Stufe eingrenzen, bevor etwas verändert wird.
-
Geplante Jobs im Vergleich: cron, systemd-Timer, launchd, Task Scheduler und AIX cron/at
Jeder Scheduler beantwortet eine Frage anders: Was passiert mit einem Job, dessen Startzeit verstrich, während der Rechner ausgeschaltet war oder schlief? Der Vergleich von cron, systemd-Timern, launchd (Kalenderschlüssel) und Windows Task Scheduler zeigt: Nur launchd holt Läufe nach dem Ruhezustand standardmässig nach, die anderen nur bei entsprechender Konfiguration.
-
systemd rescue.target und emergency.target: aufrufen und zum Normalbetrieb zurückkehren
rescue.target startet das Basissystem und eine Single-User-Shell; emergency.target überspringt fast alles und startet eine Shell auf der Konsole, wobei das Root-Dateisystem unter Umständen noch schreibgeschützt ist. Beide Targets werden über den Kernel-Parameter systemd.unit= erreicht, und beide erfordern danach die bewusste Rückkehr zu default.target.
-
Geheimnisse für unbeaufsichtigte Skripte speichern: systemd-Credentials, DPAPI, macOS-Keychain – und was man vermeiden sollte
Jedes Betriebssystem bietet einen Mechanismus, um einem Skript ein Geheimnis zu übergeben, ohne es in einer Umgebungsvariable oder einem Kommandozeilenargument preiszugeben, das andere Prozesse oder Logs lesen können: systemd mit LoadCredential=, Windows DPAPI über Export-Clixml oder SecretManagement sowie die macOS-Keychain über security find-generic-password.
-
Service-Manager im Vergleich: systemd, launchd, Service Control Manager, SRC und rc.d/OpenRC
Jedes Allzweck-Betriebssystem besitzt eine Instanz, die Dienste startet, stoppt, überwacht und beim Booten startet, doch Befehle und Persistenzmodell unterscheiden sich. Diese Referenz ordnet Start, Stopp, Status, Aktivierung beim Boot und Log-Zugriff bei systemd, launchd, dem Service Control Manager von Windows, SRC unter AIX sowie rc.d unter FreeBSD und OpenRC unter Alpine einander zu.
-
systemd-Journal mit journalctl abfragen: Unit, Boot, Priorität, Zeitraum und JSON-Ausgabe
Mit journalctl lässt sich das systemd-Journal nach Unit, Boot, Priorität und Zeitraum filtern und maschinenlesbar ausgeben, aber nur, wenn das Journal über Neustarts hinweg persistent gespeichert wird. Die Methodik behandelt präzise Abfragen, persistente Speicherung und die Grössenbegrenzungen in journald.conf.
-
Einen unbekannten Linux-Host identifizieren, bevor etwas daran geändert wird
Bevor ein Agent oder Operator die Konfiguration eines Linux-Rechners ändert, den er nicht selbst aufgebaut hat, sollten Distribution, Kernel, Virtualisierungs- bzw. Container-Status, Init-System, Paketmanager und Zustand der Mandatory Access Control geklärt werden – jeweils mit einem wenig aufwendigen, nicht destruktiven Befehl.
-
/etc/fstab sicher bearbeiten: UUIDs, nofail, x-systemd-Optionen und findmnt --verify
Eine fehlerhafte Zeile in /etc/fstab kann beim nächsten Start in eine Emergency-Shell führen. Diese Methodik verwendet UUID= statt Gerätenamen, nofail und x-systemd.device-timeout= für optionale Mounts sowie findmnt --verify und mount -a, um die Datei vor dem Neustart zu prüfen.
-
Exit-Codes von systemctl: is-active, is-enabled, is-failed und die Bedeutung von LSB-Code 3
Die systemctl-Unterbefehle is-active, is-enabled und is-failed dokumentieren eine einfache Festlegung auf 0 oder ungleich null (in der Praxis mit LSB-artigen Werten wie 3 für inaktiv und 4 für eine unbekannte Unit), während systemctl status der älteren LSB-Konvention für Init-Skripte folgt, bei der 3 «läuft nicht» bedeutet und keinen Ausführungsfehler. 3 oder 4 als fehlgeschlagenen Aufruf zu lesen, ist der häufigste Grund, weshalb Agents systemctl falsch interpretieren.
-
Dauer- und Intervall-Strings: ISO 8601, Go ParseDuration, systemd, Prometheus, PostgreSQL und .NET TimeSpan
PT1H30M, 1h30m, '1h 30min' und 01:30:00 können dieselbe Zeitspanne beschreiben, doch jeder Parser akzeptiert ein anderes Alphabet von Einheitenkürzeln und weist alles andere zurück. Ein zwischen Systemen kopierter Dauer-String lässt sich deshalb oft schlicht nicht parsen.
-
Speicherdruck unter Linux richtig lesen: free, Swap, OOM-Killer und OOMScoreAdjust
Nicht die Spalte «free», sondern «available» in der Ausgabe von free zeigt den tatsächlichen Spielraum an, und ein unter Speicherdruck beendeter Prozess verschwindet nicht spurlos, sondern hinterlässt einen Eintrag im Kernel-Log oder Journal. Der Artikel erklärt, was auszuwerten ist und wie sich beeinflussen lässt, welchen Prozess der OOM-Killer auswählt.
-
Namensauflösung auf einem systemd-Host diagnostizieren: resolvectl, resolv.conf, nsswitch und getent im Vergleich zu dig
Auf einem Host mit systemd-resolved verweist /etc/resolv.conf meist nur auf einen lokalen Stub-Listener, die tatsächlichen DNS-Server pro Link zeigt resolvectl an, und /etc/nsswitch.conf bestimmt, ob getent hosts überhaupt DNS befragt. Die Verwechslung dieser Ebenen erklärt die meisten Meldungen der Art «dig funktioniert, die Anwendung aber nicht».
-
Kernel-Parameter unter Linux mit sysctl setzen: Änderungen zur Laufzeit versus /etc/sysctl.d
sysctl -w ändert einen Kernel-Parameter nur bis zum nächsten Neustart; für eine dauerhafte Änderung gehört eine Datei in /etc/sysctl.d/, und die Ladereihenfolge über /usr/lib, /etc und /run muss bekannt sein. sysctl --system wendet alle konfigurierten Dateien an und zeigt bei Konflikten, welche Datei sich durchsetzt.
Maschinenlesbar: JSON