@msfree
MSfree hat geschrieben:Thema verfehlt, 6
Manchmal muss ich einfach erst mal ne Runde mit meinem Hund spazierengehen und währenddessen darüber nachdenken, ob ich nicht vielleicht doch unrecht haben könnte. Das ist ja wirklich nicht auszuschließen. Um mir darüber also selber Klarheit zu verschaffen, möchte ich dir zwei einfache Fragen stellen.
Stell dir das folgende hoch-komplizierte
Szenario vor.... die drei Jobs A, B und C sollen gestartet werden. Dabei muss B nach A gestartet werden, und zwingend vor C. Also nix besonderes, leicht nachzuvollziehen.
Nun kann ich mir 3 Service-Units schreiben und diese 3 Unit in gewünschter Reihenfolge manuell via systemctl starten. Ich kann mir aber genauso gut auch die ExecStart-Statements aus den Units nehmen und die Binaries damit einfach direkt starten. Beides funktioniert, beides muss im Endergebnis aufs gleiche rauskommen, und zwar das die drei Jobs erfolgreich ihre Arbeit verrichten. Und nun die erste Frage an Dich:
Was hat systemd bei genau diesem Ablauf mit dem erfolgreichen Start dieser 3 Jobs zu tun, in welcher Verantwortung ist es dabei? Mein Anwort ist: a=überhaupt nichts, b=überhaupt keine. Das wird umso deutlicher, wenn ich -wie angedeutet- die Binaries direkt starte.... obwohl es hier völlig egal ist, ob ich das via Unit oder direkt tue. Gibt es Fehler in der Job.conf oder beim Start, sehe ich die hier und ich muss sie korrigieren. Aber dafür brauch ich doch kein systemd.... und den zuvor hergestellten Zusammenhang zu systemd verstehe ich überhaupt nicht.
Wenn ich nun diese 3 Jobs nicht mehr manuell starten will, sondern beim systemstart, dann trage ich kurzerhand in die Unit des Jobs 'B' die beiden Statements "after a und before c" ein und hänge alle 3 an das passende Target oder, wie ich das bei netzwerkrelevanten Jobs tue, in Abhängigkeit nach meiner Unit "network_wait_online". Und jetzt die zweite Frage an Dich:
Wo ist hier der Unterschied zu meinen obigen manuellen Starts via systemctl oder zum direkten Start der Binaries? Was ist hier anders, dass man jetzt hier zusätzlich irgendwas weiteres kontrollieren, ausgeben oder sonstwas anstellen muss, um zu sehen, ob es läuft. Ich sage, man braucht keine Streichhölzer, um eines anzuzünden, nur um dann über die Position des Lichtschalters zu sehen, dass das Licht aus ist.
Um festzustellen, dass Jobs ordentlich eingestellt sind, brauch ich kein systemd. Und wenn sie ordentlich eingestellt sind, laufen die mit oder ohne systemd. systemd muss den Kram doch nur starten.... sonst nix.
scientific hat geschrieben:Ich denke auch, dass die Erwartungshaltung an systemd zu hoch ist.
Genau das denke ich auch. systemd ist doch wirklich nix anderes als ein quasi-cleverer Scheduler zum Starten irgendwelcher Jobs. Und das macht es parallelisiert, dynamisch und flexibel interpretiert richtig toll. Dann ist es noch ein bissken Buchhalter, indem es die Jobs vernünftig verwaltet, damit auch der Shutdown in umgekehrter Reihenfolge ordnungsgemäß ablaufen kann. Und es bietet mir darüber hinaus noch viele weitere gute Gimmicks, die mir das Arbeiten erleichtern. Ich denke auch, dass systemd völlig unberechtigt eine viel zu große Bedeutung beigemessen wird, und das -hier m.E. total unpassend- Sachverhalte durcheinander geworfen werden.