Login
Newsletter
Werbung

Thema: Systemd 245 freigegeben

54 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
6
Von Akusari am Mo, 9. März 2020 um 13:49 #

Bin ich gegen systemd ? Nein - Ganz im Gegenteil, denn ich mag den Service und Timer Teil im Systemd ungemein. Es ist wirklich angenehm das nun bei fasten allen grösseren Distris systemd zum Einsatz kommt. Es macht die Arbeit leichter und wesentlich angenehmer zwischen verschiedenen Distris. :-)
Systemd wurde seiner Zeit ins Leben gerufen um den Bootvorgang zu vereinheitlichen und logische Abhängigkeiten von Diensten mit einander zu verbinden. Eine Parallelisierung der Aufgaben sorgt dabei gleichzeitig für einen beschleunigten Bootvorang. Gut, ich frage mich zwar heute immer noch was das bringen soll, denn schließlich bootet man ja nicht alle 5 Minuten ein Server oder Desktopsystem, aber bringen die paar Sekunden wirklich etwas?
However, aus dem *Blickwinkel* der eigentlichen Idee von Systemd, muss man spätestens jetzt zum Schluss kommen, das man weit über das Ziel hinausgeschossen ist.
Gibt es schwächen im UNIX system hinsichtllich passwd oder group ? Ja natürlich, aus heutiger Sichtweise auf jeden Fall, oder zumindest kommt auf den Anwendungsfall an. Der Linux-Nerd@home wird davon wohl weniger profitieren, schließlich ist dieser meistend der einzige aktive User auf seinem System. Anderes sieht es natürlich mit den Servern in Firmen aus. Im geschäftlichen Umfeld wird man wohl auch auch die neuen Möglichkeiten der Home-Dirs u schätzen wissen. Aber - gibt es denn wirklich so viele ?
Der Apache oder Oracle Server da draussen juckt das wohl weniger.
Drum stellt sich die Frage der Zweckmässigkeit über das Verhältnis der Produktivität in soweit, ob sich alles und jedes Systemd unterordnen sollte und wenn das passiert ob wir dann die "Büchse der Pandora" geöffnet haben ? Die Legende sagt, einmal geöffnet wird man sie nie wieder schließen können!
Aber was soll da schon passieren, jetzt haben wir bald alles aus einer "Hand" und das hat ja auch seine Vorteile! Spart Zeit, Geld und vielleicht sogar den einen oder anderen Arbeitsplatz. :-)

[
| Versenden | Drucken ]
  • 7
    Von Alter Sack am Mo, 9. März 2020 um 14:43 #

    […] muss man spätestens jetzt zum Schluss kommen, das man weit über das Ziel hinausgeschossen ist.

    Es wäre ehrlicher gewesen, wenn Lennart Poettering von Anfang an zugegeben hätte, ein eigenes Betriebssystem machen zu wollen. Dieses Auswuchern von systemd wurde von etlichen Kritikern klar und deutlich vorhergesagt. Es wollte nur keiner hören. Ich selbst bin mittlerweile froh um systemd, denn so war ich gezwungen, ein paar scheinbare Gewissheiten zu hinterfragen. Am Ende bin ich dann bei FreeBSD gelandet. Diesen Schritt hätte ich schon viel früher machen sollen – auch ohne das leidige Thema systemd. Um GNU/Linux ist es halt schade.

    Dieser Beitrag wurde 2 mal editiert. Zuletzt am 09. Mär 2020 um 15:12.
    [
    | Versenden | Drucken ]
    4
    Von Anonymous am Mo, 9. März 2020 um 15:15 #

    Auch ich finde es im Arbeitsalltag extrem angenehm, mit System Service unter Timer Units zu arbeiten.
    In meiner Zeit, als ich mit Linux angefangen habe, hatte ich noch die klassischen SysV-Init Skripte geschrieben.
    Systemd hat dies extrem vereinfacht.
    Zu den "auswuchernden" Funktionen kann ich nur sagen, dass ich einige davon interessant finde (Passwd im JSON Format) und andere für mich persönlich unnötig sind (systemd-home).
    Ich nehme mir aber nicht heraus, zu behaupten, dass andere Anwender dieselben Anforderungen haben wie ich.
    Daher arbeite ich nach dem Prinzip: brauche ich nicht, nutze ich nicht, statt systemd als nicht für mich maßgeschneidert zu verteufeln.
    Eine vielleicht etwas weit her geholte Analogie ist der Linux Kernel selbst: Millionen Zeilen Code für Treiber für Hardware, welche ich gar nicht besitze.
    Nutze ich deswegen ausschließlich Gentoo um mir nur maßgeschneiderte Kernel für mein System kompilieren zu können? Die Antwort ist: Nein. Ich Benutze den Standard-Arch Kernel und ignoriere die installierten Treibermodule, welche ich nicht benötige und auf meinen Systemen im Prinzip nur Platz verschwenden.

    [
    | Versenden | Drucken ]
    • 4
      Von schmidicom am Di, 10. März 2020 um 09:35 #

      Hätte ich kaum besser schreiben können, man könnte lediglich noch hinzufügen das viele Distributionen systemd in mehrere Pakete unterteilen und bei weitem nicht standardmässig alle von Anfang an mitinstallieren.

      [
      | Versenden | Drucken ]
    1
    Von Ghul am Mo, 9. März 2020 um 19:14 #

    Gut, ich frage mich zwar heute immer noch was das bringen soll, denn schließlich bootet man ja nicht alle 5 Minuten ein Server oder Desktopsystem, aber bringen die paar Sekunden wirklich etwas?

    Als Gamer ist man froh, wenn der Gameserver ein paar Sekunden früher nach dem Reboot wieder da ist.

    Das einzige was ich an systemd kritisieren würde ist, dass man ihn in C und nicht in Rust geschrieben hat.
    Da wird es also noch einige Sicherheitslücken und Bugs geben, die durch die Wahl einer für solche kritischen Prozesse geeigneteren Programmiersprache vermeidbar gewesen wären.

    [
    | Versenden | Drucken ]
    • 2
      Von RipClaw am Mo, 9. März 2020 um 19:55 #

      Rust gab es in dieser Form noch nicht als mit der Entwicklung an systemd gestartet wurde.

      Die Arbeiten an systemd begannen 2010 und Mitte des selben Jahres hat Mozilla Rust angekündigt aber es war noch ein Prototyp und längst nicht für den Produktiveinsatz geeignet. Die erste Pre-Alpha Version von Rust kam erst 2012. Die erste stabile Version von Rust kam dann 2015 und da war systemd schon sehr weit verbreitet.

      [
      | Versenden | Drucken ]
      • 1
        Von Ghul am Mo, 9. März 2020 um 20:30 #

        Gut, das dürfte natürlich auch ein Grund dafür sein.

        Dennoch würde ich es gut finden, wenn man systemd in Rust neu schreiben würde.
        Bei systemd würde das vermutlich noch Sinn machen, da es sehr neu ist.
        Bei anderen Projekten wäre das zwar auch wünschenswert, aber viele ältere Projekte sind schon recht ausgreift, so das Fehler immer seltener entdeckt werden.

        [
        | Versenden | Drucken ]
        • 2
          Von RipClaw am Mo, 9. März 2020 um 20:55 #

          Die Entwickler von systemd werden jetzt nicht unbedingt auf Rust umsteigen aber ich habe ein kleines Projekt mit dem Namen rustysd gefunden.

          Es ist ein Drop In Ersatz für systemd und kann teilweise das was systemd kann.

          [
          | Versenden | Drucken ]
          1
          Von #! am Di, 10. März 2020 um 11:17 #

          Niemand schreibt mal eben ein in jahrelanger Arbeit entstandenes Projekt in einer anderen Programmiersprache neu, in der Hoffnung, dass dann alles besser würde (und ließe in dieser Zeit die Weiterentwicklung des Projekts ruhen).

          Wer soll das bezahlen, wer hat so viel Pinke-Pinke?

          [
          | Versenden | Drucken ]
          • 0
            Von Ghul am Di, 10. März 2020 um 16:13 #

            So etwas kommt durchaus vor.
            Gnome entstand bswp. nach KDE, als man mit dem damaligen Lizenzbedingungen von Qt nicht zufrieden war und ein weiterer Desktop wie Gnome ist gewiss kein kleines Projekt.

            [
            | Versenden | Drucken ]
            • 0
              Von #! am Di, 10. März 2020 um 20:26 #

              Gnome war auch damals schon keine KDE-Reimplementation und der Codeumfang war verglichen mit dem aktuellen systemd winzig.

              [
              | Versenden | Drucken ]
              1
              Von Verfluchtnochmal_5987108 am Mi, 11. März 2020 um 04:38 #

              Völlig idiotischer Vergleich! GNOME war niemals auch nur im Ansatz ein kde rewrite sondern immer schon ein eigenständiges Projekt

              [
              | Versenden | Drucken ]
              • 0
                Von Ghul am Mi, 11. März 2020 um 10:27 #

                Du Jungspund hast offensichtlich keine Ahnung.

                Das Gnome Projekt wurde gegründet, weil bei KDE die Lizenz von Qt fragwürdig war und viele Open Source Entwickler kein Desktop Environment auf Basis eines GUI Toolkits mit fragwürdiger Lizenz aufbauen wollten.
                Von einem 1:1 Rewrite sprichst übrigens auch nur du, es ging um den Aufwand wenn man etwas, hier als Beispiel ein Desktop Environment, noch einmal aus dem Boden stampft du Nixblicker.

                Und von der Komplexität ist so ein Desktop Environment wie es Gnome ist mit systemd problemlos vergleichbar, ich würde sogar die Behauptung aufstellen, dass Gnome mit allem drum und dran, inkl. GTK mehr Codezeilen hat.

                [
                | Versenden | Drucken ]
                • 1
                  Von Verfluchtnochmal_5987108 am Do, 12. März 2020 um 01:41 #

                  Du Kasperle ich kenne beide Desktops aus den Anfangstagen, trotzdem hast du das Thema komplett verfehlt denn man hat eben nicht kde mit einem anderen toolkit neu implementiert sondern einen völlig anderen Desktop geschrieben der damals schon grausig war

                  Du hast sogar noch auf die gesteigerte From, nämlich einer 1:1 Neuimplementierung in einer anderen Sprache geantwortet was erst recht niemand macht

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von Ghul am Do, 12. März 2020 um 09:48 #

                    Da du als Jungspund zu der Zeit noch Windeln lagst, kann das, was du schreibst nicht stimmen.

                    Das Thema habe ich keinesfalls verfehlt, da es um die Projektgröße und um eine Analogie geht, aber das willst du nicht verstehen, weil du ja Recht behalten möchtest.
                    Gnome ist sogar in C geschrieben, während KDE in C++ daher kommt. Daher ist das sogar bezogen auf den Sprachwechsel gut vergleichbar.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von Verfluchtnochmal_5987108 am Do, 12. März 2020 um 18:07 #

                      Kasperle es ging darum Code der 1:1 das gleiche tun soll komplett neu in einer anderen Sprache zu implementieren und auch wenn du Dümmling es nicht verstehen willst: Das ist bei kde versus gnome schlicht und ergreifend nicht passiert

                      [
                      | Versenden | Drucken ]
        0
        Von Hans3l am Di, 10. März 2020 um 09:38 #

        Also ist systemd veraltete legacy und es wird Zeit das jemand systemd von Grund auf neuententwickelt.

        [
        | Versenden | Drucken ]
    1
    Von RipClaw am Mo, 9. März 2020 um 19:41 #

    Systemd wurde seiner Zeit ins Leben gerufen um den Bootvorgang zu vereinheitlichen und logische Abhängigkeiten von Diensten mit einander zu verbinden. Eine Parallelisierung der Aufgaben sorgt dabei gleichzeitig für einen beschleunigten Bootvorang. Gut, ich frage mich zwar heute immer noch was das bringen soll, denn schließlich bootet man ja nicht alle 5 Minuten ein Server oder Desktopsystem, aber bringen die paar Sekunden wirklich etwas?

    Es gibt durchaus Szenarien bei denen ein schneller Start von Vorteil ist. Beispielsweise kann man Container bauen die erste hochgefahren werden wenn einer der Dienste im inneren aufgerufen wird. Das kann man über SocketActivation machen. Wenn der Container flott startet merkt der aufrufende überhaupt nicht das der Container überhaupt nicht online war.

    SocketActivation ist eine lustige Funktion von systemd die erst mal auf dem gwünschten Port horcht ob dort Datenpakete ankommen und erst dann den Dienst oder Container startet wenn der Bedarf besteht. Ich weiß z.B. von Providern die php-fpm Prozesse über SocketActivation starten. Jeder Nutzer bekommt einen php-fpm Prozess und systemd horcht auf der Socket ob eine Anfrage rein kommt und startet dann den Dienst. Da manche Seiten eher selten aufgerufen werden muss auch nicht ständig ein php-fpm Prozess laufen. Nach einiger Zeit wird der php-fpm Prozess dann wieder gestoppt wenn keine weiteren Anfragen kommen. Damit kann man eine menge Webseiten auf einen Server packen ohne das System mit Prozessen zu belasten die sinnlos laufen.

    Die Abhängigkeiten sind auch so eine Geschichte die ich nicht mehr missen möchte. Wenn ich einen Dienst starte weiß ich das alle Abhängigkeiten vorhanden sind die ich benötige. Und wenn ich den Dienst neu starte dann kann ich konfigurieren das verbundene Dienste ebenfalls neu gestartet werden. Beispielsweise der Seafile Server Dienst besteht aus zwei Diensten die in Abhängigkeit zueinander stehen. Wenn ich den einen neuen starte wird der andere automatisch auch neu gestartet.

    [
    | Versenden | Drucken ]
    • 1
      Von Ghul am Mo, 9. März 2020 um 20:54 #

      SocketActivation ist eine lustige Funktion von systemd die erst mal auf dem gwünschten Port horcht ob dort Datenpakete ankommen und erst dann den Dienst oder Container startet wenn der Bedarf besteht.

      Bezogen auf Dienste, nicht Container, ist das allerdings nichts neues.
      Das gab's auch schon in anderer Form.

      [
      | Versenden | Drucken ]
      • 1
        Von RipClaw am Mo, 9. März 2020 um 21:12 #

        Das meiste was systemd kann ist nicht neu aber vorher hat man davon nur wenig benutzt weil es relativ umständlich war und man erst an dem Init Skript rumfummeln musste. Namespaces, CGroups und Prozesslimitierungen um nur ein paar Beispiele zu nennen. Gab es vorher schon aber wurde nur wenig benutzt.

        [
        | Versenden | Drucken ]
    1
    Von Falk am Mo, 9. März 2020 um 20:05 #

    Bei der Büchse der Pandora war neben allen möglichen Übeln auch die "Hoffung" drin.

    Keine Ahnung, welche Schlüsse man daraus ziehen sollte ...

    [
    | Versenden | Drucken ]
4
Von Andre_001 am Mo, 9. März 2020 um 18:17 #

Kann mir jemand den Vorteil im Vergleich zu Plaintext Logs erklären? Ich sehe bei Logs im Binärformat in der Praxis überwiegend Nachteile.

[
| Versenden | Drucken ]
  • 2
    Von Ghul am Mo, 9. März 2020 um 19:31 #

    Das Filtern und übersichtliche Darstellen der Informationen ist einfacher und fehlerfreier durchzuführen, als bei Plaintext.

    Aus Programmierersicht ist es bequemer und man kann sich das schreiben eines eigenen Parsers sparen.
    Man kann sich auch alles als json ausgeben lassen und dann mit einem entsprechenden json Parser weiterverarbeiten.

    [
    | Versenden | Drucken ]
    • 1
      Von kamome umidori am Mo, 9. März 2020 um 21:29 #

      > fehlerfreier

      ;)

      [
      | Versenden | Drucken ]
      2
      Von Andre_001 am Di, 10. März 2020 um 08:50 #

      Dem gegenüber stehen sonderwege anstatt less/grep etc pp, für das übertragen von logfiles, der analyse von aussen, der analyse auf defekten dateisystemen etc pp

      [
      | Versenden | Drucken ]
      • 0
        Von klopskind am Mi, 11. März 2020 um 11:12 #

        Sind diese "Sonderwege" denn tatsächlich nötig und nicht nur möglich?

        1. Wenn Sie das Lesen der Logs mittels gängiger Unix-Werkzeuge meinen, so sei gesagt, dass es Pipes schon relativ lange gibt und das ist auch kein Teufelszeug. Dadurch kann man die gewohnten zeilenorientierten und textzeichbierenden Verarbeitungs- und Filterwerkzeuge von byte streams verwenden.

        Aus rein informationstechnischer Sicht können strukturierte Daten aber abhängig vom konkreten Fall auch enorme Vorteile bei der Suche und Analyse ggü. etwa klassischen zeilenorientierten Formaten aufweisen.

        Und falls ein journalctl+Pipe nicht gewünscht ist, so kann man selbst mit systemd (systemd-journald) weiterhin das Log vom Werkzeug der Wahl erstellen lassen. Einfach rsyslogd etc. installieren und die Logs weiterleiten. Da werden ganz klassisch unstrukturierte Textdateien abgelegt, die mit den traditionellen Werkzeugen allein (d.h. ohne ein journalctl+Pipe) untersucht werden können.
        Problem gelöst.

        2. Zur Übertragung von Logs stehen mit systemd-journald mWn mehr Möglichkeiten zur Verfügung als ohne, denn alle bisherigen Methoden sollten auch weiterhin funktionieren - ggf. nach einer Installation des gewünschten Log-Werkzeugs und einer Weiterleitung der Logs an dieses.
        An welche Methode der Übertragung, die mit systemd-journald nur noch über "Sonderwege" funktioniert, hatten Sie hierbei gedacht? Ist die Installation eines rsyslogd, ggf. samt Konfiguration der Weiterleitung von journald, bereits so ein "Sonderweg"? Und das würde ja nur Neusysteme bzw. Major-Revision-Upgrades betreffen, oder?

        3. Mit Analyse von aussen meinen Sie die Analyse mittels eines Zweitsystems? Ist das nicht einfach nur ein spezieller Fall des Lesens der Logs? Man braucht natürlich eine hinreichend aktuelle Version von systemd. Soweit ich weiß, hat sich das Binärformat der Logs von systemd-journald in den letzten Jahren nicht so stark verändert, sodass verschiedene Versionen kompatibel sein müssten.

        Außerdem sollte es immer auch noch ein Rescue-System im initramfs mit der selben Version geben. Und wenn selbst das Rescue-System nicht nutzbar ist, hat man gleich noch ganz andere Probleme.

        Zudem wäre besteht dieses Problem nach einer erfolgreichen Übertragung der Logs gar nicht. Man analysiere einfach die übertragenen Logs statt der lokalen auf direktem Weg.

        4. Was meinen Sie mit Analyse auf defekten Dateisystemen genau? Ein korruptes Dateisystem ist korrupt. Da hilft auch nicht der beste Logger oder die besten Unix-Werkzeuge.

        Oder können "less/grep etc pp" korrupte Dateisysteme reparieren und einbinden? Das wäre mir neu und würde für mich an Magie grenzen.

        Und welche von diesen Werkzeugen stünden mit systemd-journald nicht mehr zur Verfügung? Welche Wege kann man damit nicht mehr gehen? Welche "Sonderwege" müsste man dort gehen?

        Ich halte ein korruptes Dateisystem für ein völlig getrenntes Problem zur Analyse von Logs. Das liegt mindestens ein Schicht tiefer. Das auf den Unterschied von Text-/Binärlogs zu schieben, ist ungerechtfertigt.

        [
        | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung