Login
Newsletter
Werbung

Thema: Systemd 230 sorgt für Diskussionen

76 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von naklar am Mo, 30. Mai 2016 um 13:23 #

wann sorgt systemd für keine Diskussionen.

wenn ich jedoch die derzeitige Diskussion recht verstehe geht es weniger um systemd selbst als um welche default werte für die Konfiguration bzw das starten von Applikationen/Services verwendet wird.

ist doch einfach. alles was nicht ausdrücklich um längeres leben bittet beenden.
wenn ich screen oder sonstiges so zulassen will das es sich anders verhält, einfach entsprechend konfigurieren.
Rein prinzipiell sollte man sich in der heutigen zeit kein reboot mehr von irgendwelchen da hergelaufenen update Fanatikern verlangsamen lassen, noch dazu um 90 Sekunden!
Uptime allein gibt kein 99.9%, fast reboot jedoch schon. Das gilt für embedded und server

[
| Versenden | Drucken ]
  • 2
    Von ------------------------------ am Mo, 30. Mai 2016 um 17:32 #

    > ist doch einfach. alles was nicht ausdrücklich um längeres leben bittet beenden.

    Der Punkt ist, das systemd jetzt per default die daemon() funktion der libc ins Leere laufen läßt, nohup funktionslos wird und *sämtlicher* client code gefälligst systemd spezifische Alternativen zu daemon() Aufrufen einbauen soll - weil GNOME es nicht hinkriegt, seine 1001 daemons beim logout sauber zu beenden.

    Seit 30 Jahren *ist* nohup die ausdrückliche Bitte, den Prozess nicht mit der shell zu beenden - SIGHUP wurde überhaupt nur dafür eingeführt.

    Und der Gipfel ist, daß, sobald Nuzer linger erlauben, verbuggte Prozesse jetzt eben systemd-spezifisch fälschlicherweise überleben.

    Und wenn die beschissene Entschuldigung verzögerungen beim Shutdown sind hätte ich da einen gaaaanz gewagten vorschlag:

    logout: SIGHUP
    shutdown: SIGTERM

    Und im übrigen können deadlocks in verbuggten Prozessen immer noch ein SIGKILL erzwingen, vermutlich ist das dann der nächste "Standard" beim logout.

    tl;dr: halbgarer systemd workaround für GNOME bugs schrottet jetzt das gesamte System.

    Yeah???

    [
    | Versenden | Drucken ]
    • 1
      Von Shalok Shalom am Mo, 30. Mai 2016 um 23:47 #

      Ganz einfach: Es ist ein build trigger. Your choice

      [
      | Versenden | Drucken ]
      1
      Von krake am Di, 31. Mai 2016 um 10:23 #

      Ich verstehe in dieser Diskussion auch nicht, warum nicht einfach nohup so angepasst wird, dass weiterhin seine Funktion erfüllen kann.

      Dann hätte man das kombinierte Verhalten, also explizit längerfristig gestartete Prozesse bleiben auch weiterhin am Laufen und normale User Sessions werden fein aufgeräumt.

      [
      | Versenden | Drucken ]
      • 1
        Von Shalok Shalom am Di, 31. Mai 2016 um 11:32 #

        Es ist wahrscheinlich eine politische Motivation: Die Kritiker meinen hier eine unpassende Voreinstellung zu detektieren, was ja in Ordnung ist.

        Da es hier so leicht ist, sich zu entscheiden, versteh ich echt nicht, was technisch daran auszusetzen ist, ein Feature zu implementieren.

        Hier ist der Commit, falls es jemanden interessiert: https://goo.gl/TERTO7

        Eine Zeile, so viel Aufregung: https://github.com/KaOSx/core/blob/master/systemd/PKGBUILD#L76

        [
        | Versenden | Drucken ]
        • 1
          Von krake am Di, 31. Mai 2016 um 11:55 #

          Ich kann den Ärger an sich schon verstehen, es ergibt sich dadurch ja eine Verhaltensänderung.

          Die Distributoren hätten mit der Änderung des Standardwertes warten müssen, bis die von ihnen ausgelieferten Versionen von nohup/tmux/screen entsprechend weiterhin funktionieren.

          Ich finden nur den Ärger an das falsche Ziel gerichtet. systemd kann ja nichts dafür, wenn Distributionen ein optionales Feature ohne entsprechende Tests bzw. angepasste Hilfsprogramme aktivieren.

          [
          | Versenden | Drucken ]
          • 0
            Von schmidicom am Di, 31. Mai 2016 um 15:55 #

            Ich finden nur den Ärger an das falsche Ziel gerichtet. systemd kann ja nichts dafür, wenn Distributionen ein optionales Feature ohne entsprechende Tests bzw. angepasste Hilfsprogramme aktivieren.
            Zum einen das und zum anderen macht der Sessionmanager von systemd auch nur das was man von einem guten Sessionmanager auch erwarten können sollte.

            Nur so als Beispiel:
            Es würde vermutlich auch kaum einer auf die Idee kommen sysvinit die Schuld zu geben wenn sich z. B. ConsoleKit nach dem ausrollen einer neuen Default-Konfiguration so verhalten würde.

            [
            | Versenden | Drucken ]
        1
        Von ------------------------------ am Di, 31. Mai 2016 um 11:44 #

        Den patch doch bitte in daemon() unterzubringen war wohl auch (vor monaten) die Antwort der tmux Entwickler. Dann wäre das geänderte Verhalten nur bei homebrew doubleforks aufgefallen und verm. nichts passiert.

        Warum hier wissentlich Inkompatibilitäten hergestellt werden, läßt sich ohne VT kaum erklären. Daher vermutlich auch die harrsche Reaktion.

        [
        | Versenden | Drucken ]
        • 1
          Von krake am Di, 31. Mai 2016 um 11:59 #

          Da haben wohl die Paketbetreuer der jeweiligen Distribution nicht entsprechend miteinander kommuniziert.

          Insofern ist es eigenartig, dass das gleich bei mehreren Distributoren der Fall war, dass also bei mehreren Distributoren der Betreuer der systemd Konfiguration den Wert geändert hat und gleichzeitig die Betreuer der libc noch keine aktualisierte Versionen zur Verfügung hatten.

          [
          | Versenden | Drucken ]
          • 1
            Von ------------------------------ am Di, 31. Mai 2016 um 13:51 #

            Afaik gibt es überhaupt keinen entsprechenden patch für libc.

            systemd hat den default *upstream* geändert, die distros setzen das jetzt gerade erstmal wieder zurück.

            Für mich persönlich läuft das unter "Lennartware halt - was willst Du erwarten" *zuck*

            [
            | Versenden | Drucken ]
    1
    Von dodo am Mo, 30. Mai 2016 um 18:21 #

    wann sorgt systemd für keine Diskussionen.
    Heute?
    Hier bei PL?

    Zumindest der obige Thread dreht sich eher um Debian und ist es eine eher-für-Server-Distri oder doch nicht.

    [
    | Versenden | Drucken ]
4
Von TrollDog am Mo, 30. Mai 2016 um 20:52 #

mit Linux bist der Chef vom eigenem System. War wohl mal, Pötthering oder wie der auch heissen mag ist jetzt Cheffe, und ihr seine Lakeien. Anders herum gesagt; Linux war so vermurkst, das anscheinend Prozesse sich nicht beendeten. Was für ein scheiss OS ist das den? Und jetzt mit systemd erst Recht, hehe.

[
| Versenden | Drucken ]
  • 2
    Von CRB am Di, 31. Mai 2016 um 07:22 #

    mit Linux bist der Chef vom eigenem System

    Bist du nach wie vor, dieses (Un)Feature ist ein configure-flag.

    Pötthering oder wie der auch heissen mag ist jetzt Cheffe

    Ich wage mal zu bezweifeln, dass sich der Pott-Hering für unsere Systeme interessiert (wenn, dann würde nicht so ein Mist dabei raus kommen).

    Linux war so vermurkst, das anscheinend Prozesse sich nicht beendeten

    Nein, nicht Linux, sondern GNOME.

    Und jetzt mit systemd erst Recht

    SysV, Upstart, Init-NG, es gibt nach wie vor genügend Alternativen.

    [
    | Versenden | Drucken ]
    • 2
      Von DogTroll am Di, 31. Mai 2016 um 07:30 #

      openrc vergessen, meiner bescheidener Meinung nach noch das beste.

      Mit den anderen Einwänden bin ich mit dir ja noch konform. Bin mal Gütig ne? :-)
      Schöner Tag

      [
      | Versenden | Drucken ]
      • 2
        Von manjarone am Di, 31. Mai 2016 um 15:13 #

        Nur das es gar nicht um systemd geht. der Init spielt keinerlei Rolle. Es geht um die sitzungsverwaltung logind. Was bringt openrc nochmal für eine mit?

        [
        | Versenden | Drucken ]
        • 1
          Von hurz am Di, 31. Mai 2016 um 19:09 #

          natürlich geht es um systemd, weil logind ein teil davon ist. systemd ist eben nicht nur ein init, sondern - ja was denn eigentlich? kann bei dem willkürlich zusammengewürfelten haufen an funktionen niemand mehr sagen...

          übrigens ist auch openrc kein init, sondern ein service-manager. sysvinit oder das hier sind init-daemons:
          https://gist.github.com/rofl0r/6168719

          [
          | Versenden | Drucken ]
2
Von mw am Di, 31. Mai 2016 um 20:55 #

Kannste so machen aber ist halt Kacke. So wie systemd und GNOME im Allgemeinen.

Wann lernen die Entwickler endlich, daß nicht ihre Erwartungen an das System maßgebend sind, sonder die der Nutzer!

SO war FOSS nie gedacht und so funzt der Bazar auch nicht. Besinnt Euch!

[
| Versenden | Drucken ]
2
Von wurzel am Di, 31. Mai 2016 um 22:07 #

und dass sofort hier die Post abgeht, wenn auch nur ansatzweise systemd im Artikel erscheint ...

Nichts einigt die Wut-linuxer mehr als Hass auf das Andersartige ..

Bloß kein systemd in der Nachbarwohnung .. alles soll so bleiben wie es war ..

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 31. Mai 2016 um 22:08.
[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung