staging.inyokaproject.org

Guter Beitrag. Bisher wusste ich gar nichts von einem cron Ersatz in systemd, Hoffentlich ist das für Normalsterbliche besser verständlich 😛

Danke dafür!

Gar kein Wort darüber, dass systemd wegen der sehr Linux-spezifischen Funktionen nur begrenzt für andere Unixoiden wie FreeBSD in Frage kommt? Das war doch einer der stärkeren Kritikpunkte, upstart ist immerhin generell einfacher zu portieren und die Entwickler stehen dem auch offener gegenüber.

Das vermisse ich aber allgemein etwas in der Presse, vor allem, da Debian selbst auch offiziell mit FreeBSD Kernel zu haben ist. Letztendlich heißt das ja auch, dass die doppelte Arbeit, die einige bei Debian durch eine Festlegung auf ein System umschiffen wollten, weiterhin getan werden muss.

Abgesehen davon bin ich aber von systemd recht angetan. Dass Shuttleworth so plötzlich umschwingt und sich wieder auf Debian ausrichtet kam wirklich etwas überraschend.

Hier ging RedHats Plan auf über GNOME systemd in Debian und somit in die komplette Linux Landschaft zu erzwingen.

Da der Artikel hier sehr subjektiv und euphorisch pro Systemd ist sollte man trotzdem erwähnen, dass systemd alles andere als unumstritten ist. Auch kamen während der Diskussion des Debian Komitees eklatante Mängel von Systemd zum Vorschein.

Ein riesen Problem an dieser Monokultur ist, dass sie eben nicht nur eine Monokultur ist, sondern auch noch nur von einer kommerziellen Firma betreut wird, die nun das Monopol am Initsystem von Linux hält. Welchen Preis die Linux Community später dafür zahlen muss wird sich zeigen.

@3: Bei OpenSource Software? Sollte sich RedHat mal daneben benemen, dann ist der Preis ein Fork. Fertig.

Aber Verschwörungstheorien sind natürlich schöner.

@3: Och, nicht schon wieder... Nenne mir bitte mal einen "eklatanten Mangel", der *nicht* darauf abziehlt, dass systemd Linux-only ist.
An systemd entwickeln Leute von RedHat, Attachmate, Canonical, Mageia, Debian und ettlichen weiteren Firmen und Institutionen, es ist also mit nichten ein RedHat-only projekt. Grade auf der FOSDEM wurde ein Patch eines RedHat-Entwicklers zurückgewiesen. In der Beziehung ist systemd also ein FOSS-Projekt wie jedes andere. Sollte sich das irgendwann ändern kann man das projekt auch immer noch forken.

Die "großen" Mängel an systemd kann man auf 3 reduzieren:

1. Es ist so komplex!!!!

2. Es verwendet binary Logfiles!!!!

3. Es geht nur unter Linux!!!!

Zu der Sache mit der Komplexität wurde schon viel geschrieben, das mit den binary Logfiles ist ein überschaubares Problem so lange man sicherstellt das journalctl auch broken Logfiles noch ausgewertet bekommt wenn mal ein Bit gekippt ist.

Es geht nur unter Linux, das ist für mich sogar ein Vorteil. Wir haben so viel Features im Kernel die wir nicht nutzen weil wir gerne alles so wie früher machen. Und für sysvinit läuft bei Hurd wohl ein Translator damit das überhaupt geht. Die Installationszahlen von kfreebsd und hurd sind absolut betrachtet selbst beim sehr offenen Debian wohl eher aus dem Bereich der Messtoleranz.

Link zeigt auch deutlich das systemd Beiträge von 495 Personen hatte, bei Upstart waren es immerhin 18. Was genau ist jetzt die One-Man/One-Company Show? Belege deine Thesen bitte mit Fakten, nicht mit Spekulationen.

mfg Stefan Betz

@2: Das wurde im offiziellen und neutralen Artikel gleich nebenan durchaus erwaehnt.

Und da gibt es auch Loesungen, die so gut wie null Portierung benoetigen, wie etwa OpenRC. Und es scheint fuer Distributionen durchaus machbar zu sein, beides anzubieten. So habe ich aus Spass an der Freude am Samstag mein System in ca. 30 Minuten von OpenRC auf systemd umgestellt. In weniger (weil nun ja vorbereitet) koennte ich wieder zurueck. Also fuer Distributionen, welche mehr als nur Linux anbieten, ist es nicht wirklich ein Problem. Bis auf den Mehraufwand, dass man zwei Systeme warten muss. Aber den hat man eh.

Fuchs

@2: Wen interessiert denn, dass systemd nur in Linux läuft? Den 20 Nutzer von KFreeBSD? Den BSD'lern selbst ist das doch egal. Warum sollten sie, nur weil systemd auch nur existiert, auf einmal ein Problem damit haben?

@3: Du bist schon lustig: In jeder Diskussion um MIR verteidigst du den Display Server, der

auch noch nur von einer kommerziellen Firma betreut wird.

Ich meine mich sogar zu erinnern, diesbezüglich Zeilen im Sinne von "lasst sie doch, soll sich das Bessere durchsetzen" von dir gelesen zu haben.

Und nun wo Red Hat dasselbe macht, kritisierst du genau das, was du bei Canonical immer verteidigst.

Wenn ich hier nicht alles falsch verstanden habe, muss bei einem Umstieg auf ein anderes Init-System zwar viel angepasst werden, aber es ist immerhin noch möglich.

Sollte Canonicals MIR dagegen eines Tages zum Exklusiv-Target von proprietären Treiben seitens z.B. Nvidia werden (und die Gefahr besteht meiner Meinung nach!), dann war es das mit der freien Auswahl. http://www.heise.de/open/meldung/Ubuntu-Mir-statt-Wayland-und-Unity-zukuenftig-mit-Qt-1816015.html

Ich finde es schön, dass Mark mit diesem Statement zeigt, dass er nicht verbissen in seine eigenen Lösungen ist. Was Kritik an systemd angeht, so finde ich es, neben dem fehlenden Not-Linux-Support, vor allem schade, dass sich systemd nicht mehr so ganz dem "KISS-Prinzip" unterordnen lässt. Aber ich fürchte, das ist ein allgemeiner Trend, da die Notwendigkeit dieser Philosophie (knapper Speicher) einfach nicht mehr gegeben ist.

Spannend wird ja auch zu sehen, ob jemand Upstart forkt, um es weiter zu entwickeln 😉

@10: Die Wahrscheinlichkeit dafür halte ich für sehr gering. Eher forkt jemand systemd oder stellt dafür nötige Funktionen bei BSD/Hurd bereit.

mfg Stefan Betz

@9: Je nachdem, was du als Anforderung nimmst, folgt systemd sehr wohl dem KISS-Prinzip - nur geht es halt von einem wesentlich komplexeren Problem aus, weshalb die "einfachste Lösung" eben auch etwas aufwändiger ist. 😉

@12: Wobei die komplexen Probleme nur für 1% der Nutzer von Belang sind. 99% der User haben einfache Probleme und kämen mit einem ebenso einfachen Init-System wunderbar zurecht.

Mich stört gar nicht so sehr, dass man versucht, Linux zu modernisieren. Nur bindet man sich mit systemd nicht nur ein Init-System sondern ein gewaltiges, komplexes Monster ans Bein und schafft einen Single-Point-Of-Failure, den kein einziger Mensch mehr überblickt. Das ist quasi ein OS in einem OS, das wie ein schwarzes Loch sämtliche klassischen Unix-Funktionen und -Dienste ansaugt und gewaltsam assimiliert.

Dabei ist gerade die Modularität von Linux seine große Stärke. Jetzt fehlt aber bald nur noch ein Kernel und fertig ist das monolithische Poettering-OS.

@13: Die 1% sind dann aber halt auch oft Administratoren und Entwickler welche die Probleme der 99% lösen "dürfen".

Sorge mal bei sysvinit dafür das ein Prozess durch ein Init Script als bestimmter User gestartet werden soll, geht nur wenn das Script das vorsieht. Bei upstart würde (vermutlich) immerhin noch ein .override File ausreichend sein, bei systemd kann ich ganz genau diesen einen Wert überschreiben und den Rest vom Distributor übernehmen.

mfg Stefan Betz

Kann jemand erklären, warum systemd-journald binary logfiles einsetzt? Ich habe bisher immer die Vorzüge der rein textbasierten log- und config-files geschätzt. Außerdem tauchen im Netz immer wieder Berichte auf, dass bei schweren Abstürzen binary logs nicht mehr lesbar sein sollen.

Ich habe mir dazu noch kein Urteil gebildet, aber auf den ersten Blick sieht das wie ein Rückschritt aus?

Dann sag doch einfach dem systemd-journald er möge die Daten nach wie vor an dein Syslog weiterreichen und nichts selbst speichern.

Ich gehe schon davon aus das die Entwickler den binary Kram so konstruiert haben das er nicht gleich auseinander fällt wenn mal ein Bit kippt. Und wenn das unser einziges Problem an systemd, dann lassen wir das halt ins syslog schieben.

Und wer schon mal für einen bestimmten Dienst die Logfiles (und nur die!) gesucht hat wird journald schätzen, einfach journalctl -r -a -u dienstname und ich hab alles zusammen was ich brauche. Kein Suchen ob das jetzt in messages, debug oder everything (oder nirgends) steht. Bei systemctl status dienst sehe ich direkt die letzten Einträge aus dem Log, gleich neben dem Status ob das Ding gerade gestorben ist. Dazu habe ich wenn ich möchte auch noch die Coredumps gleich mit im Log, und diese Sache mit logrotate und voll laufendem /var/log kann ich mir auch sparen.

Das Logs also binary sind, das ist eines meiner wenigsten Probleme. Zumal nach einem richtigem Crash auch bei syslog nichts im Log steht weil die ganze Kiste samt Kernel verstorben ist.

mfg Stefan Betz

Ah verstehe - jetzt werden die Vorzüge auch langsam klar. Danke für die Erklärung!

@16: Besser hätte man es nicht zusammenfassen können ☺

Allgemein gesagt ist das binäre Log eine Datenbank, die nicht nur Plain-Text-Lognachrichten enthält, wie das klassischerweise mit Textfiles der Fall war, sondern auch Metadaten zu jedem Logeintrag. Zeitstempel, Schweregrad oder eben der Dienst, durch den der Eintrag erzeugt wurde. Dadurch werden Fehler auch in der journalctl-Ansicht rot eingefärbt. Neben dem Beispiel aus @16 mit Filterung nach Dienstname ist beispielsweise auch eine Filterung nach Zeitraum möglich, etwa mit den Parametern "--since" und "--until" oder "-b" (seit dem letzten Boot oder für einen bestimmten Boot). Weitere Vorteile kann man der journalctl-manpage entnehmen (ist natürlich noch nicht in Ubuntu enthalten, aber sicher im Netz auffindbar).

Häufig habe ich Beschwerden gelesen, dass man angeblich nicht durch das Log greppen kann, weil das mit Textdateien ja so praktisch war (ich finde, die Suche im journalctl-Pager genügt meist schon). Allerdings geht natürlich "journalctl | grep ..". Außerdem gab es die Beschwerde, dass tail -f nicht geht, weil das Log keine Textdatei ist. Dafür geht jedoch einfach "journalctl -f". Ein weiteres Argument gegen binäre Logs ist, dass man ja in eingeschränkten Umgebungen kein "journalctl" für die Wiedergabe des Logs hat. Stimmt natürlich, aber vielleicht gehört ja journalctl bald zur Standardausstattung selbst in busybox-artigen Umgebungen oder Recovery-Systemen, so wie eben grep. Das binary ist in Arch Linux ARM "nur" etwa doppelt so groß wie grep, wäre also womöglich noch akzeptabel. Es werden allerdings noch shared libraries benötigt (libgcrypt, librt, liblzma, libacl).. Geht natürlich sicher auch kompakter. Wäre doch was für BusyBox. ☺

Noch zu @13: 99% der User kommen denke ich mit jedem Init-System zurecht, weil sie dieses nie "aktiv" benutzen, also Dienste aktivieren, deaktivieren, manuell starten oder auf Probleme hin untersuchen (Logs betrachten). Das einzige was für diese User womöglich entscheidend ist, ist die Bootgeschwindigkeit. Die anderen 1% der User interagieren aber auch mit dem Initsystem, und da ist SysVInit wirklich sehr unbequem gewesen. Die Frickelei mit ellenlangen redundanten Init-Skripts für jeden einzelnen Service ist jetzt zum Glück bald vorbei. Mit einer wenige Zeilen langen systemd-Unit-Datei kann man heute eine zuverlässigere Funktion erreichen als mit einem ausgefuchsten Shell-Skript. Man bekommt automatischen Neustart von crashenden Diensten, einfache Mittel für die Festlegung der Ausführungsbedingungen (Unix-User etc.) komfortables Logging und deutlich mehr ("man systemd.service") kostenlos dazu. Außerdem überwacht systemd mittels des Linux-spezifischen Kernelfeatures "cgroups" die gestarteten Dienste und stellt sicher, dass auf Nutzerwunsch der Dienst inklusive aller Kindprozesse beendet wird. Dies war mit SysVInit nicht möglich, Upstart hat hier einen Schritt in die richtige Richtung unternommen, jedoch gab es zum Entwicklungszeitpunkt noch keine cgroups, so dass die Unterstützung noch nicht perfekt ist und auf einer eigentlich für das Debugging gedachten Schnittstelle basiert. Über cgroups ist außerdem eine faire Ressourcenteilung zwischen verschiedenen Diensten möglich, auch wenn ein Dienst sehr viele Prozesse nutzt und ein anderer Dienst nur aus einem Prozess besteht. Es wäre schade, dieses Linux-Feature aus Rücksicht auf den Debian BSD/Hurd-Port brachliegen zu lassen.

TL;DR: ich würde systemd auch dann nutzen wollen, wenn es nur halb so schnell wie SysVInit wäre. Auf die Features kommt es an. ☺

@19: Mein Problem ist ja gar nicht, dass das Init-System nicht modernisiert werden müsste. Was das angeht finde ich systemd wirklich gar nicht übel. Es ist zu Anfang etwas ungewohnt aber wenn man einmal die Idee begriffen hat, ist es wirklich viel schneller und flexibler als SysV.

Mich stört, dass systemd praktisch das ganze Linux-System an sich reißt und in einen riesigen monolithischen Blob packen möchte (Systemstart, Geräteverwaltung, Journaling und und und). Also alles, was ein Unix-System ausmacht. Bald schreibt Poettering noch einen Kernel und einen Displayserver und fertig ist das Poettering-OS.

@20:

Mich stört, dass systemd praktisch das ganze Linux-System an sich reißt und in einen riesigen monolithischen Blob packen möchte (Systemstart, Geräteverwaltung, Journaling und und und).

Systemd ist unterteilt in einzelne Komponenten die mehr oder weniger problemlos ausgetauscht werden können. Was es nicht ist, ist ein rießiger, monolithischer Blob.

Also alles, was ein Unix-System ausmacht. Bald schreibt Poettering noch einen Kernel und einen Displayserver und fertig ist das Poettering-OS.

Inwiefern wäre das ein Problem? Die Herkunft ist doch erst einmal egal, was wichtig ist, ist der Code.

Ich habe selbst Zweifel ob es so gut ist, wenn man alles in ein einziges Projekt integriert. Andrerseits wird die Zusammenarbeit der einzelnen Komponenten untereinander dadurch besser. Und bis jetzt hatte ich daduch auch nur Vorteile.

Die Wahlmöglichkeit ist aber auch nur theoretischer Natur wenn alle großen Distributionen auf die Poettering-Monokultur setzen. Ein LFS mit angepasster Struktur oder andere exotische Lösungen haben zwar auch ihren Reiz aber in der Praxis für ein Produktivsystem taugen sie aber nicht viel.

Wenn einem Software. in Abhängigkeit vom Entwickler, nicht gefällt sollte man eh auf *BSD wechseln, fast jede gängige Linux Distribution hat wesentliche Teile von Lennart Poettering im Einsatz.

Die Anzahl der Distributionen (für Desktops, Server) die kein udev (gehört zu systemd, und läuft auch ohne), avahi oder pulseaudio haben ist doch sehr überschaubar.

mfg Stefan Betz

@22: Mono? 😈

http://de.wikipedia.org/wiki/Mono-Projekt