Re: systemdesaster
On Samstag, 11. Juni 2016 21:35:41 CEST Christian Knoke wrote:
> Moin,
Morgen Christian,
> habe mal Debian 8.3 neu installiert. Der Bootvorgang von der neuformatierten
> SSD geht wahnsinnig schnell.
>
> Dann habe ich der fstab ein paar Einträge hinzugefügt, mit UUIDs für externe
> Platten und Sticks.
>
> Neustart: es wird auf einen "depending job" gewartet, 1 min 30 sec lang.
> Völlig unklar, wie in dunkelsten Windowszeiten, was los ist.
>
> Erst danach gibt es den Hinweis auf einen fstab-Eintrag. Und ich lande im
> single mode.
>
> Warum warted das System auf eine völlig unbedeutende Partition einer
> USB-Platte, die nicht angesteckt ist?
>
> Der betreffende Eintrag hat die auto Option gesetzt, die anderen Geräte
> stehen auf "noauto".
Willkommen in der systemd-Welt.
Das ist eine der vielen Policy-Änderungen, zu denen systemd-Upstream-
Entwickler Benutzer von Linux-Systemen nicht gefragt haben.
Du möchtest ein "nofail" bei jedem Dateisystem, das die Kiste nicht zum Booten
braucht. Das steht wohl auch in den Releasenotes. Ich selbst für "/boot"
gesetzt.
Meines Erachtens wäre dafür beim Aktualisieren ein dickes, fettes debconf-
Fenster fällig gewesen.
Im Grunde gibt es zwei Probleme:
1) Geänderte Semantik. Bei Wissen davon, umgehbar mit "nofail."
2) Kaputtes Konzept für die Rettungskonsole: D.h. kein Netzwerk, kein SSH,
kein gar nichts. Zumindest war das in CentOS 7 so, ich denke aber es ist auch
bei Debian so. Zumindest war dies das Feedback beim einer systemd-
Veranstaltung auf der Debconf 2015 in Heidelberg
Ich hab das beides damals, da es mir auf CentOS 7 mit einem /boot passierte,
das ich mit LABEL=boot eintrug und dabei vergaß, auch das Label zu setzen, in
den RedHat-Bugtracker eingekippt: Ergebnis ist, sie wollen nicht von Upstream
abweichen und ich dürfe das bitte mit Upstream diskutieren.
Derzeit? "No way". Nach meiner letzten Erfahrung irgendetwas Kontroverses auf
systemd-devel anzusprechen, setze ich keinen Fuß mehr auf die Liste. Als
Lennart selbst, der doch über den Umgangston auf der LKML klage, als "Now you
are being a dick" bezeichnete, also persönlich angegriff, überschritt er eine
Grenze, die ich ihn nicht überschreiten lasse.
Technisch finde ich Vieles bei Systemd sinnvoll.
Richtlinien-mäßig jedoch auch vieles kaputt.
Dieses gehört dazu. Warum?
Wenn ich einen Server neu starte möchte ich eines: Die Kiste kommt wieder
hoch.
*Immer*.
Das Wieder-Hochkommen beim Neustart hat für mich einen großen Wert, ich pfeife
da auf 100%-ige Korrektheit, weil Probleme kann ich immer noch beseitigen,
wenn die Kiste via SSH erreichbar ist.
Systemd-Entwickler implementierten jedoch: Entweder der Boot ist korrekt, oder
es geht in eine wenig brauchbare Rettungskonsole, die auf Out of Band-
Management setzt, da nicht mal SSH funktioniert. Das geht soweit, dass ich SSH
nicht mal per systemctl start ssh starten läßt. Denn was passiert dann: Er
guckt wieder nach dem Dateisystem, das sich nicht Mounten lässt, und geht dann
nach eineinhalb Minuten wieder in die Rettungskonsole. Ich tippte dann "/usr/
bin/sshd" ein. Und nein, das ist kein Witz. Das war auf dem CentOS 7
tatsächlich so kaputt.
Und sozial?
Geht gar nicht für mich derzeit.
Vielleicht irgendwann, zu hoffen ist es, aber das ist nach wir vor mein
Hauptkritik-Punkt. Wie systemd-Upstream-Entwickler mit anderen Mitgliedern der
Community umgehen, die Arroganz in Bezug auf Bugreports und anderer Kritik am
Verhalten von systemd – das geht für mich gar nicht. Und persönlich meine ich
hier vor allem Lennart und Kay. Andere waren durchaus verständiger.
Es hat ja einen Grund, dass systemd so kontrovers war und noch ist. Es war ja
nicht so, dass Leute einfach nur rumtrollen wollten – natürlich, die gab es
auch und gibt es hin- und wieder wohl mal. Aber es gab und gibt viele Leute,
die meines Erachtens vollkommen berechtigte Kritik haben.
Ein guter Upstream erwägt diese ernsthaft. Und genau das fehlt hier.
Ciao,
--
Martin
Reply to: