Ist im Endeffekt eine Frage, was man als "reines Init" bezeichnet. Ist das wirklich nur das Programm /sbin/init, oder gehören da auch die Skripte/Units dazu?
Die Skripte wurden/werden von der Shell verarbeitet, also streng nach dem Unix Prinzip. Systemd macht das in der Standardkonfiguration natürlich nicht. Ich kann der Idee mehr abgewinnen, wenn jedes Projekt seine eigenen Skripte pflegt statt alle in ein Korsett zu pressen weil die ganze Welt nur noch Linux und Systemd nutzt.
Scripte sind keine Konfigurationsdateien, die Konfiguration von SystemD und die Units sind Textdateien. Ein Tool wird von SystemD genau so umgesetzt, für jede Aufgabe gibt es ein Tool oder ein Daemon die Lose über eine API verbunden sind. Interoperabilität bei Init-Skripten ist eine Lüge. Hast Du schon mal versucht ein Init-Skript von einer Linux Distribution auf eine andere Distribution oder ein Unix zu übernehmen?
Natürlich sind sie das. Du kannst über Umgebungsvariablen das Skript steuern, mehr noch als Systemd. Die komplette Implementierung ist in einer Skriptsprache samt Kommentaren gegeben. Systemd ist erstmal ein binärer Blob, theoretisch in Modulen aufgeteilt, praktisch sind Userland Gegenstücke kaum noch nutzbar oder gar supported. Nur weil irgendwelche Deppen bei den Distros Verhalten und Pfade hart setzt, heißt es nicht das sie nicht austauschbar sind.
Nur weil irgendwelche Deppen bei den Distros Verhalten und Pfade hart setzt, heißt es nicht das sie nicht austauschbar sind.
Natürlich heißt es das nicht, aber in der Praxis waren sie eben nicht austauschbar. Nicht nur wegen der Pfade, sondern vor allem auch, weil jeder ein etwas anderes Format der Skripte genutzt hat.
Die Skripte wurden/werden von der Shell verarbeitet, also streng nach dem Unix Prinzip.
Das Zitat, auf das du dich vermutlich beziehst sagt ja: Do one thing and do it properly.
Ob das mit dem "properly" so stimmt kann man allerdings bezweifeln. Die Skripte waren teilweise ja ziemlich komplex und dublizierten eine Menge Code. Ich glaube nicht, dass die Macher von Unix daran Gefallen gefunden hätten.
Abgesehen davon hat man nichts davon, wenn man blind an einem Prinzip (oder in diesem Credo) festhält. Man muss sich schon Gedanken darüber machen, was wo und wie Sinn macht. Wobei ich eigentlich sogar eher der Meinung bin, dass systemd diesem Credo besser folgt als sysvinit. Dennoch sehe ich das nicht als wichtig an, sondern eher, dass es seine Aufgabe gut erledigt (und da gibt es sicher noch einiges zu tun, aber es sieht nicht so schlecht aus).
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.
Ist im Endeffekt eine Frage, was man als "reines Init" bezeichnet. Ist das wirklich nur das Programm /sbin/init, oder gehören da auch die Skripte/Units dazu?
Die Skripte wurden/werden von der Shell verarbeitet, also streng nach dem Unix Prinzip. Systemd macht das in der Standardkonfiguration natürlich nicht.
Ich kann der Idee mehr abgewinnen, wenn jedes Projekt seine eigenen Skripte pflegt statt alle in ein Korsett zu pressen weil die ganze Welt nur noch Linux und Systemd nutzt.
Wo steht in der Unix Philosophie das Init-Script von der Shell bearbeitet werden müssen bzw. sollten?
Textdateien zur Konfiguration, eine Tool - eine Aufgabe, Interoperabilität.
Scripte sind keine Konfigurationsdateien, die Konfiguration von SystemD und die Units sind Textdateien. Ein Tool wird von SystemD genau so umgesetzt, für jede Aufgabe gibt es ein Tool oder ein Daemon die Lose über eine API verbunden sind. Interoperabilität bei Init-Skripten ist eine Lüge. Hast Du schon mal versucht ein Init-Skript von einer Linux Distribution auf eine andere Distribution oder ein Unix zu übernehmen?
Natürlich sind sie das. Du kannst über Umgebungsvariablen das Skript steuern, mehr noch als Systemd. Die komplette Implementierung ist in einer Skriptsprache samt Kommentaren gegeben.
Systemd ist erstmal ein binärer Blob, theoretisch in Modulen aufgeteilt, praktisch sind Userland Gegenstücke kaum noch nutzbar oder gar supported. Nur weil irgendwelche Deppen bei den Distros Verhalten und Pfade hart setzt, heißt es nicht das sie nicht austauschbar sind.
Ob das mit dem "properly" so stimmt kann man allerdings bezweifeln. Die Skripte waren teilweise ja ziemlich komplex und dublizierten eine Menge Code.
Ich glaube nicht, dass die Macher von Unix daran Gefallen gefunden hätten.
Abgesehen davon hat man nichts davon, wenn man blind an einem Prinzip (oder in diesem Credo) festhält. Man muss sich schon Gedanken darüber machen, was wo und wie Sinn macht. Wobei ich eigentlich sogar eher der Meinung bin, dass systemd diesem Credo besser folgt als sysvinit. Dennoch sehe ich das nicht als wichtig an, sondern eher, dass es seine Aufgabe gut erledigt (und da gibt es sicher noch einiges zu tun, aber es sieht nicht so schlecht aus).
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.