systemd, der nächste Horror für BSD?
- Ersteller Elwood
- Erstellt am
- Status
nakal
Anfänger
Ich habe das Gefühl, dass ich auf Ressourcenverwaltung (erstmal in Jails!) schon ewig gewartet habe... es bewegt sich da nichts.
Das Konzept modular in einem System zu machen, ähnlich wie cgroups und zwar so, dass man es auch in Jails anwenden kann, wäre schon eine interessante Erweiterung des Konzepts, nur Jails mit Ressourceneinschränkungen auszustatten.
Hier sollte FreeBSD es wirklich wie Microsoft machen... Konzept kopieren, aber so, dass es besser wird als alles bestehende.
Das Konzept modular in einem System zu machen, ähnlich wie cgroups und zwar so, dass man es auch in Jails anwenden kann, wäre schon eine interessante Erweiterung des Konzepts, nur Jails mit Ressourceneinschränkungen auszustatten.
Hier sollte FreeBSD es wirklich wie Microsoft machen... Konzept kopieren, aber so, dass es besser wird als alles bestehende.
Wenn die Realität immer so einfach wäre. Willkommen in der Welt von 3rd-Party-Software, die wegen bestimmter Bugs - bekannt, aber ungelöst - manchmal einfach nicht korrekt anläuft. Gern praktiziert von branchenspezifischer Software, für die es genau einen Anbieter gibt, der sich entsprechend Zeit mit der Fehlerbehebung lassen kann. Oder den Bug einfach gar nicht behebt.
Wie stellt man als Admin in diesem Fall die Ursache ab?
Ob eine Software benötigt wird, liegt im Normalfall nicht im Ermessen des Admins, sondern der Anwender bzw. Fachbereiche. Einen Admin, der die Bezeichnung verdient, erkennt man auch daran, dass er solche Herausforderungen bewältigt.
Beide Projekte listen Linux als unterstützte Plattform auf:
- http://mmonit.com/wiki/MMonit/SupportedPlatforms
- http://supervisord.org/introduction.html#platform-requirements
Wie in der Dokumentation beschrieben, solltest du dafür auch den "Emergency Mode" verwenden, nicht den "Single-User Mode".
Es gibt leider Software, die horizontal gar nicht und vertikal sehr bescheiden skaliert. Dort ist es dann einfach preiswerter und vernünftiger, Ressourcen-Limits setzen zu können.
Software hat Fehler, und manche Fehler führen dazu, dass Dienste nicht korrekt starten - unabhängig vom Betriebssystem.
In vielen Fällen lässt sich die Ursache vom Admin nicht beheben, erst recht nicht kurzfristig. Der Dienst sollte aber trotzdem eine möglichst hohe Verfügbarkeit haben - dafür wird der Admin schließlich bezahlt.
Die Diskussion hatten wir schon bei ZFS. Ich persönlich empfinde systemd transparenter als das vergleichbare Konglomerat von Diensten, das mit mehr Code, komplexeren Abhängigkeiten und komplizierterer Konfiguration weniger Funktionalität zur Verfügung stellt.
Allerdings. Ich würde mich freuen, mal wieder einen innovativen Meilenstein wie Jails in FreeBSD 4.0 im Jahre 2000 (sic!) oder einen genialen Schachzug wie die Integration von ZFS in FreeBSD 7.0 im Jahre 2008 zu sehen.
Kommt sicher. Ich glaube derzeit ist das ja mit pkgng im Gange.
systemd fühlt sich find ich einfach mehr nach dem Linux-Weg Dinge zu tun. Also immer mehr "magic" reinzupacken und weniger zu wissen was passiert. Das ist ja immer das Tolle an BSD, dass man weiß was los ist. Aber in dem Zusammenhang kann man auch die Sache mit xorg sehen, die ja auch in letzter Zeit sehr stark in diese Richtung gegangen sind. Man muss sich einfach eingestehen, dass das ein Projekt ist wo zum größten Teil Linux-Entwickler dahinter stehen. Da ist es nicht weiter verwunderlich, dass man sich dann für systemd ist. Ich denke das war mal anders, ist aber schon länger her.
Andererseits muss man auch fairerweise sagen, dass das jetzt sicher nicht das Ende für BSD darstellt. Man muss bedenken, dass man immer schon SysV hatte und es immer schon jede Menge Software gab, die für Linux und nicht für unixoide Systeme geschrieben wurden. Dass es jetzt systemd gibt heißt ganz sicher nicht, dass jetzt plötzlich alle ihr System so umstellen, dass es nur noch mit systemd läuft, schon garnicht so lange Debian, Gentoo und Ubuntu nicht umstellen. Und bis dahin ist systemd womöglich wieder ein anderer Hut und Portabilität und Simplizität werden wieder modern. Das ist ja auch immer mal wieder im Trend und jede Menge Projekte wie Slackware Arch Linux oder Crux sprießen aus dem Boden. Es muss nur ein Entwickler Lust und Eifer haben.
Achja, noch wegen solchen Dingen wie Verfügbarkeitshacks: Wie wäre es mit einem RC-Script mit einem Wrapper, Cronjobs, etc.? Wenn man schon dabei ist einen Hack zu implementieren ist da der Unterschied nicht groß.
-Nuke-
Well-Known Member
So wie ich das verstehe, versucht man wohl noch dagegen anzukämpfen:
https://lists.debian.org/debian-ctte/2014/02/msg00344.html
Aber naja, man kann hier nur abwarten. Egaler könnte mir nichts sein, aber man wird es ja sehen.
foxit
Well-Known Member
Um mal einen grossen Punkt bei "systemd" etwas zu entkräften und zwar den mit den binären Logfiles. Es ist möglich, "systemd" zu sagen, dass es alle Logs zu "syslog" weiterleiten soll. Habe ich nicht gewusst. Heute zufällig gesehen:
[1] http://tamcore.eu/systemd-zurueck-zu-richtigen-logfiles/
[1] http://tamcore.eu/systemd-zurueck-zu-richtigen-logfiles/
nakal
Anfänger
In erster Linie sollte ein fähiger Admin solche Frittensoftware identifizieren können und genug Charisma haben, dass ihm die Leute vertrauen, wenn er sagt, dass er sie nicht installieren möchte, weil sie die Stabilität des Betriebs gefährdet. Dann sollte er die Fehler korrigieren können.
Wenn nicht möglich und darauf bestanden wird, sollte er sie von allen Systemen abschotten, die wichtig sind und in einer Umgebung starten wo sie keinen Schaden anrichtet. Bei solchen Umgebungen braucht man auch keinen systemd, weil sie dediziert sind und strikt darauf ausgelegt sind, dass alles drin instabil ist. Diese Umgebung braucht typischerweise mehr Werkzeuge und Strategien, um Stabilität zu rekonstruieren, als einem lieb ist und ist die teuerste Art von Umgebung, in die man den meisten Aufwand reinsteckt. Da reicht ein Neustart nicht, sondern typischerweise Strategien, um kaputte Dateien zu behandeln, Sachen aufräumen, Implementierungen für Workarounds für Spezialfälle wo das Teil identifizierbar versagt uvm.
Wenn systemd für solche Frickelumgebungen gedacht ist, dann kann ich es auch verstehen. Was ich nicht verstehen kann ist warum es schwierig sein soll, einen Daemon in einer Skript-Schleife dauernd zu starten. Wo ist der Vorteil, wenn ich es deklarativ mache? Kann ich bei der deklarativen Lösung von systemd noch auf Exit-Codes reagieren, bevor ich den kaputten Daemon neu starte?
nakal
Anfänger
Das ist auch ok so. Sie haben keine Option gelassen, dass man init beibehalten würde (wollten sie offenbar nicht), dann richtet systemd vielleicht noch den kleinsten Schaden an. Wahrscheinlich mag der große Teil der Debian-Gemeinde aus ideologischen Gründen inzwischen Canonical nicht und das hat Upstart auch disqualifiziert.
-Nuke-
Well-Known Member
Zur Auswahl standen Upstart, Systemd, OpenRC und "keine Änderung".
q000te
Well-Known Member
"systemd - broken by design": http://ewontfix.com/14/
HN dazu: https://news.ycombinator.com/item?id=7207655
Ich selbst warte einfach ab wie sich das Ganze entwickelt und was aus
"Open Launchd" https://wiki.freebsd.org/launchd wird.
HN dazu: https://news.ycombinator.com/item?id=7207655
Ich selbst warte einfach ab wie sich das Ganze entwickelt und was aus
"Open Launchd" https://wiki.freebsd.org/launchd wird.
Genau, der Admin überzeugt seine Kollegen, dass sie auf Software verzichten sollten, die ihnen ein paar Millionen Euro im Jahr einbringt.
Wie korrigiert er Fehler in Closed-Source-Software?
Sehr gute Idee. Wir basteln uns eine komplexe Lösung für etwas, was systemd mit ein paar Zeilen Konfiguration kann.
Oder wir nehmen ein System, dass 90% solcher Sachen out of the box konfigurativ handhabbar macht, ohne dass man viel Aufwand treiben muss.
Ich finde es hervorragend, dass systemd nicht nur Schönwetter-Dienste berücksichtigt, sondern reale Probleme mit wenig Aufwand für den Admin lösbar macht.
Weil systemd wesentlich mehr kann als das und mit ein paar Zeilen Konfiguration das erledigt, wofür man sonst hunderte Zeilen Shell-Skript braucht.
Ja.
Bist du selber Admin, oder hast du nur mal mit welchen gesprochen?
peterle
Forenkasper
@Azayel
Was Du beschreibst könnte ich mir aus meinem Bekanntenkreis noch als "normal" vorstellen - es wirkt dennoch auf mich so, als ginge man mit einem Messer in eine Schießerei, würde sich aber dafür noch schnell ein Häkelmützchen greifen wollen, weil man nur durch die Löcher getroffen werden könne ...
Ich bin aber auch überhaupt kein Freund dieser ganzen Virtualisiererei und des ZWangs immer alles in eines packen zu wollen.
Was Du beschreibst könnte ich mir aus meinem Bekanntenkreis noch als "normal" vorstellen - es wirkt dennoch auf mich so, als ginge man mit einem Messer in eine Schießerei, würde sich aber dafür noch schnell ein Häkelmützchen greifen wollen, weil man nur durch die Löcher getroffen werden könne ...
Ich bin aber auch überhaupt kein Freund dieser ganzen Virtualisiererei und des ZWangs immer alles in eines packen zu wollen.
Zuletzt bearbeitet:
foxit
Well-Known Member
Mal noch etwas zum Thema "Bei Linux wird immer alles neu erfunden"
Auch Red Hat arbeitet an Live-Patching für den Linux-Kernel
http://www.heise.de/open/meldung/Au...e-Patching-fuer-den-Linux-Kernel-2110402.html
Auch Red Hat arbeitet an Live-Patching für den Linux-Kernel
http://www.heise.de/open/meldung/Au...e-Patching-fuer-den-Linux-Kernel-2110402.html
lme
FreeBSD Committer
IIRC gibt's so was auch für FreeBSD, aber ich finde leider gerade nichts dazu. Offiziell drin ist es jedenfalls nicht.
Nein, aber der dritte im Bunde (Ksplice, Kgraft und Kpatch...)
darktrym
Fahnenträger
Wobei Ksplice unter GPL steht(vermutlich nicht die akt. Version) und funktioniert bis auf Userland und den Service dahinter frei/kostenlos. Und das Gebiet nicht komplett patentfrei und deshalb implementieren Suse und Red Hat jeweils eine Lösung, denen muss echt langweilig sein.
foxit
Well-Known Member
WOW auf der Debian Mailingliste gehts ja echt ab 
https://lists.debian.org/debian-ctte/2014/02/msg00376.html
https://lists.debian.org/debian-ctte/2014/02/msg00376.html
lechindianer
Kritiker
Daraus könnte man den nächsten OpenBSD Release Song bauen
nakal
Anfänger
Genau, der Admin überzeugt seine Kollegen, dass sie auf Software verzichten sollten, die ihnen ein paar Millionen Euro im Jahr einbringt.
Das gibt es sehr selten und für seltene Fälle optimiert man keine Software, vor allem nicht wenn das Konzept lächerlich wird.
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. Namhafte Firmen haben oft fähige Leute, die sofort sehen, dass eine Software schlecht ist und suchen nach Alternativen.
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?
2) systemd ist wie Du sagtest deklativ. Die Workarounds sind meistens nur mit prozess-/skriptorientieren Sprachen konstruierbar.
Das sind sie auch out-of-the-box mit init. Da sind oft 10 Zeilen Konfiguration pro Dienst bei FreeBSD. Total einfach.
Wie schon gesagt: mit Dienstestarten und -beenden hatte ich noch nie Probleme.
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. Man möchte da unendliche Flexibilität (eine Turing-vollständige Sprache eben).
Ich sehe bei systemd jetzt auch nicht wirklich den Vorteil gegenüber RC-Scripts. Ich schätze auch mal, dass der Aufwand Task X in jedem realistischen System in etwa gleich hoch sein wird.
Aber das ist eigentlich auch nicht die Hauptkritik, sondern eher, dass systemd alles neu erfinden muss und alles sein will, [rant]wobei sich schön langsam die Frage stellt, warum es dann überhaupt noch Daemons starten will, wenn es sowieso meint alles besser zu können[/rant].
Mal ehrlich, alles was irgendwie in Richtung Unix geht und da zähl ich jetzt auch mal Linux dazu; hoffe ihr vergebt mir das mal. Aber all das Zeug ist ja nur so toll, weil man seine Systembausteine hat, aus denen man was aufbauen kann, die man auch ersetzen kann, sei es jetzt in Form einer neuen Version oder einem ganz anderen Softwareprojekt. Systemd ist da irgendwie extrem komisch. Es hat diese ganzen integrierten Bestandteile und dann ab und an mal ein Interface oder eine Option um ein wenig kompatibel zu sein. Ich verstehe da nicht ganz warum man nicht gleich eine Architektur baut, wo man mehrere Teile zusammenspielen lässt, mit schönen, sauberen Interfaces. Wenn man Cron neu erfinden will, warum tut man das nicht einfach sondern muss es ins "init-System" einbauen. Warum muss das alles so am Kernel dranhängen?
Lennart Poettering schreibt da immer, dass er damit irgendwie ungenutzte Features von Linux nutzt. Ich sehe da jetzt erstmal nur die oben beschriebene Zwangsjacke und dass mein Arch Linux nun schwerer zu konfigurieren ist. Vielleicht übersehe ich was ganz großes, aber irgendwie klingt das so nach unerfahrenem Programmierer, der einfach mal eine Software für alles schreiben will. Sorry, wenn das jetzt nach einem argen Angriff klingt, aber wenn ich mir das System anschaue sehe ich einfach auch Komplexität bei Dingen, wo ich weiß, dass es einfacher geht und mittlerweile ist KISS bei mir nicht nur ein Schlagwort das irgendwie cool ist, sondern das Wissen, dass es sich so auszahlt simple einfache Systeme und Interfaces zu erstellen anstatt komplexe Monolithen. Ich habe schon viel Scheitern an derartigen Systemen erlebt und erinnere mich selbst mit Scham zurück sowas gebaut zu haben. Da frage ich mich echt, was bei RedHat falsch läuft.
Ich find'e einfach Schade. Als ich zu Linux und BSD gefunden habe war die größte Herausforderung den Grafikkartentreiber in xorg einzurichten um 3D zu haben.
Viele Jahre später und jetzt ist Sound kompliziert. Und ich fürchte echt, dass ich bald keine Programme oder zumindest Daemons mehr laufen lassen kann ohne gröbere Probleme.
Aber das ist eigentlich auch nicht die Hauptkritik, sondern eher, dass systemd alles neu erfinden muss und alles sein will, [rant]wobei sich schön langsam die Frage stellt, warum es dann überhaupt noch Daemons starten will, wenn es sowieso meint alles besser zu können[/rant].
Mal ehrlich, alles was irgendwie in Richtung Unix geht und da zähl ich jetzt auch mal Linux dazu; hoffe ihr vergebt mir das mal. Aber all das Zeug ist ja nur so toll, weil man seine Systembausteine hat, aus denen man was aufbauen kann, die man auch ersetzen kann, sei es jetzt in Form einer neuen Version oder einem ganz anderen Softwareprojekt. Systemd ist da irgendwie extrem komisch. Es hat diese ganzen integrierten Bestandteile und dann ab und an mal ein Interface oder eine Option um ein wenig kompatibel zu sein. Ich verstehe da nicht ganz warum man nicht gleich eine Architektur baut, wo man mehrere Teile zusammenspielen lässt, mit schönen, sauberen Interfaces. Wenn man Cron neu erfinden will, warum tut man das nicht einfach sondern muss es ins "init-System" einbauen. Warum muss das alles so am Kernel dranhängen?
Lennart Poettering schreibt da immer, dass er damit irgendwie ungenutzte Features von Linux nutzt. Ich sehe da jetzt erstmal nur die oben beschriebene Zwangsjacke und dass mein Arch Linux nun schwerer zu konfigurieren ist. Vielleicht übersehe ich was ganz großes, aber irgendwie klingt das so nach unerfahrenem Programmierer, der einfach mal eine Software für alles schreiben will. Sorry, wenn das jetzt nach einem argen Angriff klingt, aber wenn ich mir das System anschaue sehe ich einfach auch Komplexität bei Dingen, wo ich weiß, dass es einfacher geht und mittlerweile ist KISS bei mir nicht nur ein Schlagwort das irgendwie cool ist, sondern das Wissen, dass es sich so auszahlt simple einfache Systeme und Interfaces zu erstellen anstatt komplexe Monolithen. Ich habe schon viel Scheitern an derartigen Systemen erlebt und erinnere mich selbst mit Scham zurück sowas gebaut zu haben. Da frage ich mich echt, was bei RedHat falsch läuft.
Ich find'e einfach Schade. Als ich zu Linux und BSD gefunden habe war die größte Herausforderung den Grafikkartentreiber in xorg einzurichten um 3D zu haben.
Viele Jahre später und jetzt ist Sound kompliziert. Und ich fürchte echt, dass ich bald keine Programme oder zumindest Daemons mehr laufen lassen kann ohne gröbere Probleme.
foxit
Well-Known Member
Ein weiteres Problem bei "Upstart" wäre wohl noch die Lizenz von Canonical. Diese müssten die Debianentwickler akzeptieren oder als Alternative einen Fork erstellen und diesen in Debian pflegen. Dann steht man wieder allein da. Nein wenn man es mal ganz nüchtern betrachtet, bleibt wohl wirklich nur "systemd" 
- Status