Das was man von Admins hört ist bisher: Wenn Skripte nicht funktionieren, einfach debuggen oder neustarten. Die sind zwar nicht sehr zuverlässig, aber die Fehler sind schnell identifizierbar und behebbar. Wenn Systemd nicht funktioniert, viel Spaß.
Wenn die Behebung des Problems ein kompletten Reboot notwendig macht weil das Verhalten nicht erklärbar ist, da lobe ich mir ein Restart eines einzelnen Services. Systemd bleibt bei Problemen eine Blackbox.
aber die Fehler sind schnell identifizierbar und behebbar.
Wirklich?
Ich weiß ja nicht, wie das anderen Linux-Nutzern geht, aber ich habe mit manchen Skripten schon Stunden verbracht, bis ich den Fehler gefunden habe. Teilweise auch, weil der Fehler gar nicht im Skript selbst war, sondern in einem anderen Skript, welches sich aber darauf auswirkte.
Aber kann natürlich sein, dass ich der einzige Mensch auf dieser Welt bin, der Bash Skripte furchtbar findet, zumindest wenn es um Fehlersuche in diesen geht...
> Das was man von Admins hört ist bisher: Wenn Skripte > nicht funktionieren, einfach debuggen oder neustarten. > Die sind zwar nicht sehr zuverlässig, aber die Fehler sind > schnell identifizierbar und behebbar.
Schön, wenn es so einfach ist. Ich habe schon Stunden vor init-Skripten gesessen und mir die Haare gerauft, weil komplexe Fehlerfälle nicht abgefangen wurden.
Und dazu noch die ganzen Folgen von Trivialproblemen: Z.B: ist ein Daemon nach dem kill aus dem Init-Skript doch nicht tot (trotz "ok" Ausgabe des Skripts) und streitet sich mit dem neu gestarteten daemon. Schnell behoben, als das Problem erst mal erkannt war. Die Diagnose und das Aufräumen der kaputten Daten hat dann aber insgesamt doch einen Tag gedauert.
Das was man von Admins hört ist bisher: Wenn Skripte nicht funktionieren, einfach debuggen oder neustarten. Die sind zwar nicht sehr zuverlässig, aber die Fehler sind schnell identifizierbar und behebbar. Wenn Systemd nicht funktioniert, viel Spaß.
Ja, und genau das ist eben der Unterschied: systemd funktioniert.
Wenn die Behebung des Problems ein kompletten Reboot notwendig macht weil das Verhalten nicht erklärbar ist, da lobe ich mir ein Restart eines einzelnen Services. Systemd bleibt bei Problemen eine Blackbox.
Wieso sollte sich systemd hier anders verhalten als sysvinit?
Wenn es ein Problem mit einem Service gibt -> Problem untersuchen und Service neu starten.
Wenn es ein Problem mit dem Init selbst gibt -> Reboot.
Mal ganz abgesehen davon, dass ich noch kein Problem mit systemd (bzw. seinen Units, Komponenten) hatte, das mich zu einem Reboot gezwungen hätte.
Ich weiß ja nicht, wie das anderen Linux-Nutzern geht, aber ich habe mit manchen Skripten schon Stunden verbracht, bis ich den Fehler gefunden habe.
Teilweise auch, weil der Fehler gar nicht im Skript selbst war, sondern in einem anderen Skript, welches sich aber darauf auswirkte.
Aber kann natürlich sein, dass ich der einzige Mensch auf dieser Welt bin, der Bash Skripte furchtbar findet, zumindest wenn es um Fehlersuche in diesen geht...
> Das was man von Admins hört ist bisher: Wenn Skripte
> nicht funktionieren, einfach debuggen oder neustarten.
> Die sind zwar nicht sehr zuverlässig, aber die Fehler sind
> schnell identifizierbar und behebbar.
Schön, wenn es so einfach ist. Ich habe schon Stunden vor init-Skripten gesessen und mir die Haare gerauft, weil komplexe Fehlerfälle nicht abgefangen wurden.
Und dazu noch die ganzen Folgen von Trivialproblemen: Z.B: ist ein Daemon nach dem kill aus dem Init-Skript doch nicht tot (trotz "ok" Ausgabe des Skripts) und streitet sich mit dem neu gestarteten daemon. Schnell behoben, als das Problem erst mal erkannt war. Die Diagnose und das Aufräumen der kaputten Daten hat dann aber insgesamt doch einen Tag gedauert.