Bist du selber Admin, oder hast du nur mal mit welchen gesprochen?
Ich bin eigentlich Softwareentwickler im Bereich Middleware und viel in Integrationsprojekten in Unix-lastigen Branchen unterwegs.
Dadurch bin ich reichlich in Kontakt mit solchen Problematiken unter diversen Betriebssystemen (Linux, Solaris, AIX, aber auch gelegentlich Windows) konfrontiert, die zur Umsetzung der Integrationsprobleme in den Griff gebracht werden müssen.
Das gibt es sehr selten und für seltene Fälle optimiert man keine Software, vor allem nicht wenn das Konzept lächerlich wird.
Unterschätze nicht die gigantische Menge an Individualsoftware, die genau solche Probleme hat, weil sie über Jahre und Jahrzehnte gewachsen ist, immer wieder angepasst wurde und entsprechende Abhängigkeiten zu externen Systemen hat. Ich war schon in vielen Unternehmen unterwegs, die mehr Individualsoftware in Betrieb haben als FreeBSD Ports hat.
Verhaltensanalyse, Workarounds... jede Menge Sachen sind möglich. Es ist halt teuer, sich mich mülliger Software zu beschäftigen, deswegen sollte diese im Müll landen, bevor sie Unkosten und oft auch Katastrophen verursacht.
Die Software mag oftmals alt, nicht besonders sexy und nach heutigen Maßstäben in vielen Fällen hoffnungslos veraltet sein.
Es ist aber auch die Software, mit der ein beträchtlicher Teil der Unternehmen ihr Geld verdient. Natürlich wäre es schön, diese Software in aller Ruhe auf der grünen Wiese neu zu entwickeln, aber dabei landet man sehr schnell bei astronomischen Kosten - für Software, die erstmal nicht mehr kann als der Vorgänger. Von Integrationstests, Migrationen und sonstigen Risiken ganz zu schweigen. Und dafür soll ein Unternehmen dann mal eben Millionen oder - je nach Größe - Milliarden ausgeben, mit ungewissem Ausgang?
Namhafte Firmen haben oft fähige Leute, die sofort sehen, dass eine Software schlecht ist und suchen nach Alternativen.
Wärst du mal in namhaften Firmen unterwegs, würdest du erschrecken, wieviel hochkarätige Leute an vermeintlich schlechter Software arbeiten, die aber hier, jetzt und heute funktioniert und dafür sorgt, dass das jeweilige Unternehmen überhaupt existiert. Für die es keine Alternativen gibt, weil sie genau die Aufgaben löst, die dieses Unternehmen hat. Für die es keine vergleichbare Software am Markt gibt und deren Ablösung unbezahlbar ist. Wie soll hier die Alternative aussehen?
1) Die Lösung ist angemessen in der Komplexität. Wenn sie ja so viele Millionen kostet, dann kann man auch Millionen investieren damit sie sich korrekt verhält, oder wie siehst Du das?
Es gibt reichlich Software, die historisch gewachsen ist und dadurch einfach Macken hat, die sich mit vertretbarem Aufwand nicht beheben, sondern nur in den Griff kriegen lassen.
Software, für die vielleicht ein Nachfolger in Sicht ist, dessen Produktionsreife sich aber noch Jahre (oder auch ein Jahrzehnt) hinziehen wird. In der Zwischenzeit muss die Software funktionieren.
2) systemd ist wie Du sagtest deklativ. Die Workarounds sind meistens nur mit prozess-/skriptorientieren Sprachen konstruierbar.
Mit systemd kann man eben viele Konstellationen, die man vorher nur mit reichlich 3rd-Party-Software und Skripts in den Griff bekommen hat, rein deklarativ lösen - mit deutlich weniger Aufwand und höherer Zuverlässigkeit.
Es wird natürlich auch bei systemd das eine Prozent Spezialfälle geben, bei denen man zusätzlich ein Skript haben möchte - deren Integration hat systemd aber auch vorgesehen.
Das sind sie auch out-of-the-box mit init. Da sind oft 10 Zeilen Konfiguration pro Dienst bei FreeBSD. Total einfach.
Das reicht eben für einen professionellen Betrieb oftmals nicht aus. Warum gibt es wohl so viele Projekte (launchd, upstart, openrc, systemd, smf, etc.), die sich genau solchen Problemen widmen?
Der klassische SysVinit/BSDinit reicht nur für triviale Fälle aus und wird heutigen Anforderungen nicht mehr gerecht.
Wie schon gesagt: mit Dienstestarten und -beenden hatte ich noch nie Probleme.
Die Toleranz wächst mit der Distanz zum Problem.
Nein. Kann es nicht. Es kann nicht eine spezifische wählbare Reaktion auf einen Exitcode implementieren, sondern nur auf Verhaltensklassen einige (auf einer Hand) abzählbare Reaktionen verursachen. Das ist bei den vielen Sachen, die man als Admin vor hat nicht genügend.
Auch daran wurde in systemd gedacht, die Flexibilität hat man. Mittels ExecStopPost kannst du auch beliebige Kommandos (inklusive Auswertung des Exitcode) ausführen, falls die umfangreichen deklarativen Möglichkeiten nicht ausreichen.
Man möchte da unendliche Flexibilität (eine Turing-vollständige Sprache eben).
Nein - man möchte unendliche Flexibilität haben, wenn man sie braucht. Ansonsten möchte man möglichst keinen Code schreiben. Jede Zeile Code muss geschrieben, verstanden, debugged und gewartet werden.
Aus all diesen Gründen und vielen mehr: Why systemd is winning the init wars and other things aren't.