Das beste oder nichts: systemd?

Seit Jahren nutze ich zwangsläufig systemd, da es bei allen von mir eingesetzten Distributionen zum Auslieferungsumfang gehört. Das ist wertfrei gemeint, ob das jetzt systemd heißt oder SysVinit ist mir eigentlich egal, der Krempel soll einfach nur laufen und mir möglichst wenig auf den Sender gehen. Ich bin weder systemd-Befürworter noch -Gegner, einfach nur User und Admin, der möchte, dass der Kram ohne viel Aufwand und graue Haare funktioniert.

In all der Zeit hatte ich den ein oder anderen Stolperstein, den ich hier für die Nachwelt hinterlassen möchte. Weiterhin möchte ich damit jeden zum Nachdenken anregen, was für ihn Freiheit im Sinne von Freier Software bedeutet.

Ausuferndes Monster

Je mehr ich mich mit systemd und seinen Komponenten beschäftige, wird mir immer klarer: Das SAP unter den Init Systemen, wenn es doch nur ein Init-System geblieben wäre. Was haben wir da aktuell an Komponenten: networkd, resolved, jounald, timesyncd, boot, container, timer, services und noch eine Menge anderes. Was wird da die Zukunft noch alles bringen? Ich wäre mal für einen coffeed ☕️, das würde wirklich Probleme lösen! coffeectl fill cup wird wohl noch lange auf sich warten lassen 😆

Das ist schon ziemlich viel für ein Init-System, was es eigentlich sein sollte. Hm, ein All-in-One »Dings« kann doch nicht so schlimm sein, verschiedene Komponenten können sich ja Konfigurationen teilen und mir so das Leben erleichtern. Pustekuchen! Ich finde Konfigurationsdateien an Stellen, da wusste ich nicht mal, dass es Stellen gibt. Meine aktuelle Einschätzung zu systemd ist deckungsgleich mit der zu 3D-Druckern: systemd löst Probleme, die wir ohne systemd nicht hätten.

Inkonsistente Umsetzung(en)

Bei dem Einrichten des neuen LinuxNews Hosts, kam mir etwas unter, das mich schon so lange stört: systemctl restart php [TAB]

php8.2-fpm.service  phpsessionclean.service  phpsessionclean.timer

Ein sehr lästiges Luxusproblem, den php8.2-fpm.service nicht per TAB-Taste autokompletiert neu starten zu können. Über solche Kleinigkeiten rege ich mich oftmals auf. Die Suchmaschine der Wahl angeworfen und gesucht nach systemd rename service. Viele empfahlen doch in der originalen Unit Datei zu modifizieren, mag ich nicht. Durch einen Zufall stieß ich auf einen Artikel, der vorschlug, ein Alias zu setzen.

Die Funktion eine Unit zu bearbeiten kennt man, systemctl edit php8.2-fpm.service ist das Werkzeug dafür laut Dokumentation. Aus der Unit:

[Unit]
Description=The PHP 8.2 FastCGI Process Manager
Documentation=man:php-fpm8.2(8)
After=network.target

[Service]
Type=notify
ExecStart=/usr/sbin/php-fpm8.2 --nodaemonize --fpm-config /etc/php/8.2/fpm/php-fpm.conf
ExecStartPost=-/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82
ExecStopPost=-/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

wurde:

[Install]
Alias=php.service

### Lines below this comment will be discarded
[Unit]
Description=The PHP 8.2 FastCGI Process Manager
Documentation=man:php-fpm8.2(8)
After=network.target

[Service]
Type=notify
ExecStart=/usr/sbin/php-fpm8.2 --nodaemonize --fpm-config /etc/php/8.2/fpm/php-fpm.conf
ExecStartPost=-/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82
ExecStopPost=-/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

Das obligatorische systemctl daemon-reload und systemctl daemon-reexec hinterher und … nichts. Vielleicht braucht diese Hardcore-Änderung ja ein Neustart, gesagt – getan und … nichts! Hmpf. Vielleicht mag er ja im »edit« kein [Install] haben, versuchen wir es doch mal in der originalen Unit. Dann halt doch im Original fummeln, vim /etc/systemd/system/multi-user.target.wants/php8.2-fpm.service

[Unit]
Description=The PHP 8.2 FastCGI Process Manager
Documentation=man:php-fpm8.2(8)
After=network.target

[Service]
Type=notify
ExecStart=/usr/sbin/php-fpm8.2 --nodaemonize --fpm-config /etc/php/8.2/fpm/php-fpm.conf
ExecStartPost=-/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82
ExecStopPost=-/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target
Alias=php.service

Diesmal direkt einen Neustart, ihr ahnt es: richtig nada! Es geht nicht, es ist nicht möglich, diesem Service ein Alias zu verpassen. Ob das jetzt an den PHP-Maintainern liegt oder an systemd ist mir in dem Moment als Anwender wurscht, es geht nicht – es frustriert mich. Sollte sich mein Gedanke bewahrheiten und ein [Install] durch Editieren nicht möglich sein, ist es wirklich sehr inkonsistent umgesetzt. Wofür gibt es dann die Edit-Funktion, wenn ich nicht alle Optionen einer Unit bearbeiten kann? Ein Bug könnte auch schuld sein, aber auch das ist mir als Anwender schlussendlich egal. Es bleibt die Frustration zurück, gepaart mit einem schlechten Bild vom Produkt.

Meine Lösung ist deutlich simpler und beugt graue Haare vor: echo "restartphp='systemctl restart php8.2-fpm.service'" >> /root/.bash_aliases. Keine Unit, kein Problem. Bash hat mich noch nie enttäuscht.

Debugging von Services

Mit neuen Versionen gibt es neue Funktionen und Änderungen, so weit so klar. Aber dass ein Socket und Service, die unter Debian 11 einwandfrei laufen, nun unter Debian 12 so gar nicht mehr tun, erklärt sich mir nur mit: Versionsübergreifende Kompatibilität? Kann man das essen?

Ich betreibe einen Pseudo-Honeypot auf meinen öffentlich erreichbaren Servern, der Well-Known Ports öffnet. Sobald hier eine Connection stattfindet, wird die IP gesammelt und gesperrt. Nur weil bei dem LinuxNews-Server Port 21 offen ist, heißt das noch lange nicht, dass dahinter ein FTP-Server auf Daten wartet 😉. Wer daran ebenfalls Interesse hat, muss sich noch etwas gedulden: Anleitung liegt angefangen in den Entwürfen. Zurück zum Thema.

Diese Socket und Service Dateien habe ich aus meiner Git herauskopiert und auf Debian 12 verpflanzt. Leider ist heute schon das Journal überschrieben, sonst würde ich hier mal die Crème de la Crème an nichtssagenden Fehlermeldungen einfügen. Etwas, das systemd ausgezeichnet kann: Geht nicht, aber ich sag’ dir nicht warum. Find’s doch raus, du Affe! So etwas erinnert mich immer an ein anderes Betriebssystem:

Stunden später laufen die Services und Sockets nun. Einfach nur ärgerlich und verbrannte Lebenszeit.

networkd

Den networkd und networkctl benutze ich mit Debian 12 zum ersten Mal. Einen Grund, die /etc/network/interfaces über Bord zu werfen, gibt es nicht wirklich – lediglich ein Gedankengang: Ich benötige systemd-resolved für DNSSEC und DoT, vielleicht harmoniert das ja besser mit dem systemd-eigenen Krempel.

In all den Jahren der Server- und Firewalladministration gab es noch nie den Fall, dass das Netzwerk nicht funktioniert, spätestens nach dem zweiten Anfassen der Konfigurationsdatei. Systemd ermöglicht mir hier ein völlig neues Erlebnis. 17 Neustarts und Änderungen später, ist die Konfigurationsdatei die gleiche wie initial eingerichtet – diesmal funktioniert sie aber. Alle Zeilen wurden auskommentiert, eine Zeile dazugenommen und neu gestartet – und dann wieder – und dann wieder. So kann man sich natürlich auch die Zeit vertreiben…

Ein journalctl -b | grep networkd sowie systemctl status systemd-networkd wurden natürlich zum Debugging genutzt, zeigten immer alles grün. Das einzige hilfreiche Befehl war networkctl status $NIC. State: Off. Wenn er off ist, muss er on: networkctl up $NIC, diesmal war der Status dann degraded. Ein Begriff, der mir bisher nur in Verbindung mit RAID geläufig war. Eine Suche brachte mich zu einem Issue auf github, dort wird gefragt, was degraded bedeutet ⇨ (damals) nicht dokumentiert, heute nur noch unzureichend dokumentiert.

Das letzte, nicht startende Netzwerk hatte ich mit Enterprise Linux 7, in der Datei /etc/sysconfig/network-scripts/XXX wurde ONBOOT=yes vergessen.

resolved

Der Resolved hat mir vor einigen Wochen das Nervenwasser gezogen. Solch ein schlampig vorgehendes Stück Software habe ich selten gesehen! Der Befehl zum Testen ist resolvectl query domain.de. Nach dem Einrichten der Konfigurationsdatei, nutze ich den Befehl um die Konfiguration zu verifizieren, dass sie auch tut. Ja nun, manchmal geht es und manchmal nicht. Debugging ist kaum möglich. Andere Systeme haben dieses Problem nicht, mit selbem DNS-Server.

Ein anderes Problem ist, dass manchmal überhaupt nichts passiert. Nach Stunden der Suche stieß ich auf ein GitHub Issue, dass meinen Fehler genau beschreibt. Ob der Fix in Debian 12 ankommen wird, werden wir sehen. Bis dahin muss es eben ohne gehen

Ebenfalls tragisch: Man nutzte die Google DNS-Server als Fallback. Haben die Entwickler schon einmal das Wort Privatsphäre gehört? Was soll denn das? Nicht jeder möchte Google Dienste nutzen. Eine Vorgeschlagene Idee war, Cloudflare einzutragen. Na vielen dank auch! Seit wann hardcoded man denn Konfiguration? Das letzte mal fest einprogrammierte Konfiguration habe ich vor 15 Jahren gesehen, ein CRM bei dem der Mail-Port 25 fest voreingestellt war. (Wahl)Freiheit für den Anwender? Fehlanzeige!

journald

Wer hielt es eigentlich für eine gute Idee, Log Dateien für einen Texteditor unlesbar zu machen? Natürlich können die gängigen SIEM Lösungen dieses “proprietäre” Format lesen, es erschwert Dinge an anderer Stelle.

Ein Filtern und nach Mustern via Bash Script ist nicht so einfach möglich, wie es mit einem grep oder sed mal war. Zudem erschwert es die Zugänglichkeit von Logs für neu entwickelte Programme. Hier müssen Entwickler journalctl-Handstände machen, um an die benötigte Info zu kommen. Zudem muss es jeder unterstützen – systemd hat eine enorme Verbreitung und man kommt nicht daran vorbei (Ideologisch getriebene Distros wie z.B.Devuan mal außen vor gelassen).

Früher war alles besser!, ein Spruch den ich hasse – hier muss ich aber zustimmen: Logs mit einem Texteditor lesen zu können, war eine feine Sache!

timesyncd

systemd kann auch die Zeit synchronisieren. Allerdings bis heute nicht mit NTS. Für den Großteil der Menschheit wahrscheinlich nicht relevant. Es ist mehr meine persönliche Präferenz, alles zu verschlüsseln wo es nur eben geht. Ist es aber nicht inkonsistent, ein allumfassendes Stück Software entwickeln zu wollen, dass dann solche Fälle nicht abdeckt? Ich nutze nun Chrony, das kann NTS und hat kein journald-Log.

timer

Timer werden wohl die Zukunft sein, ganz anfreunden kann ich mich damit aber nicht. Es löst kein Problem, sondern macht es nur anders. Früher reichte ein einfaches sudo -u www-data crontab -e, heute müssen es gleich zwei Dateien sein. Ein Beispiel aus der Praxis wäre der wp-cron.php.

Ich benötige einen Service:

[Unit]
Description=wp-cron.service

[Service]
User=www-data
ExecStart=/bin/bash -c php -f /var/www/wordpress/wp-cron.php

und einen Timer

[Unit]
Description=wp-cron

[Timer]
OnCalendar=*:0/15:00
Persistent=true
Unit=wp-cron.service

[Install]
WantedBy=basic.target

Es ist ein deutlicher Mehraufwand zwei Dateien zu befüllen, als ein simples sudo -u www-data crontab -e gefolgt von */15 * * * * php -f /var/www/wordpress/wp-cron.php. Welches Problem löst systemd nun mit den Timern? Das des geringen Zeitaufwands und der Simplizität garantiert…

Poettering und Microsoft …

Trotz aller Kontroversen und narzisstischem Verhalten ist das hier keine Kritik an ihm selbst. Ich sehe die Gefahr durch seinen Arbeitgeber. Der Fairness halber sollte erwähnt werden, dass auch Red Hat mir schon nicht wirklich geschmeckt hat. Meine Befürchtung ist hier einfach die “politische Einflussnahme” durch den Arbeitgeber. Das ist ja in der Vergangenheit auch schon passiert: WSL hat inzwischen systemd. Grundsätzlich ist das ja ein Mehrwert und eine positive Entwicklung.

Das war sicherlich begründet durch die Einflussnahme von Microsoft auf einen Arbeitnehmer. Hier werden Prioritäten verschoben, weil man von der Microsoft-Hand gefüttert wird. “Ich bezahle dich, du machst, was ich will!” lautet hier vermutlich die Devise. Hier wird die Zeit zeigen, wie stark und in welche Richtung die Einflussnahme gehen wird.

Für jedes Projekt wäre es nicht verkehrt, wenn es einige Guidelines geben würde, die beschreiben, worauf ein Arbeitgeber alles Einfluss nehmen kann und worauf nicht. Bei systemd habe ich keine solche Vereinbarung gefunden, es könnte also sein, dass die Microsoft Einflussnahme grenzenlos durch das Projekt wuchert. Schafft definitiv Vertrauen.

Distros, beugt euch!

Systemd ist eine Kernkomponente aller großen Distributionen. Hier sehe ich auch die Gefahr an systemd: Die Marschrichtung wird geändert und alle müssen sich, aufgrund der großen Abhängigkeit, dem beugen. Ist das noch Freie Software, wenn sich eine Distribution an »einem Paket« so derart ausrichten muss? Gezwungenermaßen müsste dann jede Distribution den Quatsch mitmachen, alternativ wird systemd geforked und entschlackt. Selbiges könnte man allerdings auch über den Kernel sagen.

Freie Software?

Wie frei ist frei, wenn eine Kernkomponente plötzlich die Richtung ändern und dadurch alle Distros sich diesem beugen müssen? Wie frei ist frei, wenn ein Hauptentwickler als Arbeitnehmer eines Konzerns finanziert wird? Wie frei ist frei, wenn der finanzierende Konzern auch noch ein Konkurrenzprodukt herstellt? Wie frei ist frei, wenn hierdurch eine massive Einflussnahme passieren kann?
Fragen, die mir durch den Kopf gehen, auf die ich aber keine Antwort finde.

DU HAST ABER XY FALSCH KONFIGURIERT !!!11!elf

Mag sein, ich habe mich an der Dokumentation von systemd als auch den Manpages orientiert. Es mag auch sein, dass z.B. Red Hat die Lösung in seiner (exzellenten) Dokumentation stehen hat. Es mag auch möglich sein, dass es dieses eine ultimative Tutorial von irgendjemandem gibt.

Etwas, das man dem Projekt ankreiden MUSS. Es ist die Aufgabe des Projektes, eine aktuelle Dokumentation bereitzustellen und nicht meine Aufgabe, mir auf irgendwelche Fetzen einen Reim zu machen oder die magische Eingebung zu bekommen.

Man konfiguriert etwas nach Dokumentation und es funktioniert nicht. Fehlermeldungen nichtssagend oder keine. Da fühlt man sich schon etwas left outside alone. Bei der Einrichtung so mancher systemd-Komponente kam ich mir vor, als würde ich zum ersten Mal einen Computer benutzen …

Fazit

Ich habe mit fast jeder systemd-Komponente Ärger oder einen nicht unerheblichen Mehraufwand. Benutzen die ihren eigenen Krempel eigentlich? Es kommt mir nicht so vor. Systemd bleibt für mich ein notwendiges Übel, besser macht es nichts. Es erhöht an mancher Stelle die Komplexität auf unnötige Art und Weise.

Was löst systemd nun?

Auf diese Frage habe ich keine Antwort, weshalb ich sie gerne an euch geben würde. Was löst systemd denn für euch? Für mich ist systemd mit all seinen Komponenten wie ubuntu und sein netplan: Anders, aber nicht wirklich besser.