Ich werde Dir nicht Deine Erfahrungen streitig machen, aber WENN systemd für Serveraufgaben nicht tauglich WÄRE, warum setzen SUSE und Red Hat voll darauf, seit Ewigkeiten? Bei Distros, die für viel Geld angeboten werden?
Er hat schon recht, mit Systemd wurde Mitnichten alles besser. Ungefähr bei jedem 10. Booten kann hier Systemd die über /dev/urandom verschlüsselte Swap-Partition nicht einhängen und wartet dann unendlich darauf, bis Swap verfügbar wird. D.h. das System hängt auf Dauer beim Booten fest. Worst case. Jetzt ist es ja nicht so, dass Verschlüsselung über /dev/urandom nicht die empfohlene Methode für Swap-Partitionen wäre oder gar, dass /dev/urandom blockieren könnte.
Wenn Systemd nun brauchbares Troubleshooting unterstützen würde, dann könnte man das als Vorteil von Systemd werten, nur dem ist ja leider nicht so. Da ist ein Workaround wie eine Swap-Verschlüsselung per statischem Keyfile bedeutend schneller umgesetzt (und damit der Fehler auch nicht mehr aufgetreten), so dass dies ebenfalls nicht für Systemd spricht.
Systemd mag vieles können, aber zuverlässiger ist der Bootvorgang durch Systemd nicht geworden und Systemd gibt es langsam lange genug, um es noch als Kinderkrankheit abtun zu können. Daran ändert leider auch das Prinzip "fresst Scheiße, Millionen von Fliegen können nicht irren" nichts.
Edit: Auch im negativen Sinne bemerkenswert sind die immer wieder mal auftauchenden "A stop job is running"-Meldungen bei denen Systemd zwar weiß, dass sich offenbar ein Job nicht beenden lässt aber unfähig ist diesen zu benennen oder gar dem Nutzer ein Mitspracherecht einräumt, den Wartevorgang einfach (z.B. mit CTRL+C) abzubrechen. Ich habe mich auf Clientsystemen schon mehrmals dabei ertappt ein solches System dann einfach hart durch Stromentzug abzuwürgen und auf das Journaling des Dateisystems zu vertrauen, anstatt minutenlang für Nichts zu warten.
Auf Serversystemen habe ich mittlerweile die Reservezeit der USV großzügig erhöht, da die Meldungen auch noch verschachtelt auftreten können und sich die Zeitspanne immer weiter erhöht und es zu einem unkalkulierbaren Risiko wird, dass dadurch noch während des Herunterfahrens der Strom ausgeht.
Systemd hat den Bootvorgang sicher schneller gemacht und hat auch sicher die Konfiguration vereinheitlicht, aber zuverlässiger ist dadurch nichts geworden.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 06. Nov 2019 um 17:32.
Er hat schon recht, mit Systemd wurde Mitnichten alles besser. Ungefähr bei jedem 10. Booten kann hier Systemd die über /dev/urandom verschlüsselte Swap-Partition nicht einhängen und wartet dann unendlich darauf, bis Swap verfügbar wird. D.h. das System hängt auf Dauer beim Booten fest. Worst case. Jetzt ist es ja nicht so, dass Verschlüsselung über /dev/urandom nicht die empfohlene Methode für Swap-Partitionen wäre oder gar, dass /dev/urandom blockieren könnte.
Wenn Systemd nun brauchbares Troubleshooting unterstützen würde, dann könnte man das als Vorteil von Systemd werten, nur dem ist ja leider nicht so. Da ist ein Workaround wie eine Swap-Verschlüsselung per statischem Keyfile bedeutend schneller umgesetzt (und damit der Fehler auch nicht mehr aufgetreten), so dass dies ebenfalls nicht für Systemd spricht.
Systemd mag vieles können, aber zuverlässiger ist der Bootvorgang durch Systemd nicht geworden und Systemd gibt es langsam lange genug, um es noch als Kinderkrankheit abtun zu können. Daran ändert leider auch das Prinzip "fresst Scheiße, Millionen von Fliegen können nicht irren" nichts.
Edit:
Auch im negativen Sinne bemerkenswert sind die immer wieder mal auftauchenden "A stop job is running"-Meldungen bei denen Systemd zwar weiß, dass sich offenbar ein Job nicht beenden lässt aber unfähig ist diesen zu benennen oder gar dem Nutzer ein Mitspracherecht einräumt, den Wartevorgang einfach (z.B. mit CTRL+C) abzubrechen. Ich habe mich auf Clientsystemen schon mehrmals dabei ertappt ein solches System dann einfach hart durch Stromentzug abzuwürgen und auf das Journaling des Dateisystems zu vertrauen, anstatt minutenlang für Nichts zu warten.
Auf Serversystemen habe ich mittlerweile die Reservezeit der USV großzügig erhöht, da die Meldungen auch noch verschachtelt auftreten können und sich die Zeitspanne immer weiter erhöht und es zu einem unkalkulierbaren Risiko wird, dass dadurch noch während des Herunterfahrens der Strom ausgeht.
Systemd hat den Bootvorgang sicher schneller gemacht und hat auch sicher die Konfiguration vereinheitlicht, aber zuverlässiger ist dadurch nichts geworden.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 06. Nov 2019 um 17:32.