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
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.
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.
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.
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.
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.
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.
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.
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?
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
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
> 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???
Ganz einfach: Es ist ein build trigger. Your choice
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.
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
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.
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.
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.
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.
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*
Ah, dann hab ich das falsch verstanden, ich dachte die Distributoren haben den Wert geändert.
So macht es natürlich Sinn, wenn der Ärger an systemd gerichtet ist.
Hier bei PL?
Zumindest der obige Thread dreht sich eher um Debian und ist es eine eher-für-Server-Distri oder doch nicht.
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.
Bist du nach wie vor, dieses (Un)Feature ist ein configure-flag.
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).
Nein, nicht Linux, sondern GNOME.
SysV, Upstart, Init-NG, es gibt nach wie vor genügend Alternativen.
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
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?
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
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!
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.dass die Dummheit der Menschheit unendlich ist. qed