Jessie/LXDE: implizite Abhängigkeit von systemd?

[hikaru]

Hallo,

ich habe hier ein Jessie-System das mit sysvinit-core läuft und auch laufen soll. Dort habe ich lxde-core ohre Suggests und Recommends installiert.
lxsession stellt ein grafisches Logout mittels lxsession-logout bereit. Damit das funktioniert braucht es das rec:upower und dessen rec:policykit-1. Letzteres wiederum hängt von libpam-systemd ab, was seinerseits von systemd abhängt.

Zusamengefasst lässt sich also sagen, dass ein LXDE-Desktop unter Jessie nicht mehr ohne Systemd betrieben werden kann. Ist das einen Bugreport wert?

[JTH]

Nabend,

Zusamengefasst lässt sich also sagen, dass ein LXDE-Desktop unter Jessie nicht mehr ohne Systemd betrieben werden kann.

ohne die Installation des Pakets systemd kommst du da wohl tatsächlich nicht aus. Das heißt aber noch nicht, dass systemd bei dir auch als Init laufen muss. libpam-systemd geht es, der Paketbeschreibung nach, hauptsächlich um den logind aus dem Paket systemd. Die Abhängigkeit von libpam-systemd zum Paket systemd-sysv, was mit sysvinit-core kollidieren würde, kannst du durch die Installation von systemd-shim, das ein paar systemd-APIs ersetzt/vortäuscht, umgehen.

[hikaru]

Die Abhängigkeit von libpam-systemd zum Paket systemd-sysv, was mit sysvinit-core kollidieren würde, kannst du durch die Installation von systemd-shim, das ein paar systemd-APIs ersetzt/vortäuscht, umgehen.

Das hatte ich soweit schon mal irgendwo gelesen, es hatte mich dann aber irritiert das ich für so eine "Dummylösung" trotzdem systemd installieren muss.

ohne die Installation des Pakets systemd kommst du da wohl tatsächlich nicht aus. Das heißt aber noch nicht, dass systemd bei dir auch als Init laufen muss.

Das finde ich konzeptionell ziemlich hässlich.
Welchen Zweck erfüllt dann systemd auf dem System, außer dass es ein paar Abhängigkeiten befriedigt?

Um das ganze Systemd-Thema hatte ich bis jetzt eher einen Bogen gemacht weil beim Versuch sich zu informieren das Signal/Rausch-Verhältnis ziemlich schlecht ist.

[uname]

Das Problem ist wohl policykit-1 und nicht Lxde. Da wohl auch Gnome und KDE nicht ohne Policykit-1 auskommen braucht man eigentlich gar nicht mehr zu diskutieren ob Systemd in der nächsten Debian-Version zum Standard wird. Auf dem Desktop ist es aufgrund dieser vollkommen bescheuerten Abhängigkeit wohl nicht zu verhindern. policykit-1 bekommt man auch ohne Suggests und Recommends sehr schnell auf die Platte, wobei ich es bei Gnome/KDE nicht probiert habe. Ich denke ein Bug Report wäre angebracht. Im Serverumfeld und bei Anwendern mit einfachen Windowmanagern wie openbox mag das alles noch recht unkritisch sein, da es Alternativen wie z.B. gksu und sudo gibt.

[hikaru]

Ich denke ein Bug Report wäre angebracht.

Um Sinn zu ergeben, also zu einem Fix zu führen, müsste das dann aber ein RC-Bug sein wenn ich Ian Jackson [1] richtig verstehe:

Degraded operation with some init systems is tolerable, so long as
the degradation is no worse than what the Debian project would
consider a tolerable (non-RC) bug even if it were affecting all
users.

Und das sehe ich nicht wenn ich mir die Kriterien für einen RC-Bug (critical+grave) [2] ansehe:

1 critical makes unrelated software on the system (or the whole system) break, or causes serious data
loss, or introduces a security hole on systems where you install the package.
2 grave makes the package in question unusable by most or all users, or causes data loss, or
introduces a security hole allowing access to the accounts of users who use the package.

[1] https://lists.debian.org/debian-vote/20 ... 00001.html
[2] viewtopic.php?f=27&t=151820&hilit=xshis ... 5#p1009293

[JTH]

Das hatte ich soweit schon mal irgendwo gelesen, es hatte mich dann aber irritiert das ich für so eine "Dummylösung" trotzdem systemd installieren muss.

systemd-shim ersetzt laut Beschreibung nur Funktionalität, die fehlt, wenn systemd nicht als Init läuft, nicht aber die anderen Dienste/Programme aus dem Paket systemd.

Das finde ich konzeptionell ziemlich hässlich.

Vielleicht wäre es klarer und würde manchem die Angst vor systemd nehmen, wenn man Teile wie systemd-logind in ein eigenes Paket verschiebt (falls das vom Aufwand her vertretbar ist)?

Welchen Zweck erfüllt dann systemd auf dem System, außer dass es ein paar Abhängigkeiten befriedigt?

Das ist doch eine häufige Aufgabe von Paketen Und in dem Paket steckt ja wie geschrieben mehr als nur der SysV-Init-Ersatz.

[…] weil beim Versuch sich zu informieren das Signal/Rausch-Verhältnis ziemlich schlecht ist.

Da hast du allerdings recht.

Auf dem Desktop ist es aufgrund dieser vollkommen bescheuerten Abhängigkeit wohl nicht zu verhindern.

Die DEs verwenden hier aber glaube ich bisher hauptsächlich nur die Möglichkeiten zum User-/Sessionmanagement (systemd-logind wieder ), statt wie bisher meist consolekit (das bisher eine Abhängigkeit von policykit-1 war). Richtige Abhängigkeiten von DEs zu systemd als PID 1 gibt es bisher keine:

Code: Alles auswählen

$ apt-cache rdepends systemd-sysv
systemd-sysv
Reverse Depends:
  sysvinit
  systemd-sysv:i386
  xfce4-session (empfiehlt alternativ systemd-shim)
  tuxonice-userui
  systemd-cron
 |libpam-systemd
 |init
  gpsd

[hikaru]

Vielleicht wäre es klarer und würde manchem die Angst vor systemd nehmen, wenn man Teile wie systemd-logind in ein eigenes Paket verschiebt (falls das vom Aufwand her vertretbar ist)?

Ich meine auf der Mailingliste zu Jacksons GR gelesen zu haben, dass die Maintainer das nur ungern tun würden, da Systemd eigentlich nicht für so eine Modularisierung ausgelegt ist und es daher viel Arbeit bedeuten würde - zumal keine Unterstützung (in Form von einfacherer Trennbarkeit in der Zukunft) von Upstream zu erwarten ist.

Welchen Zweck erfüllt dann systemd auf dem System, außer dass es ein paar Abhängigkeiten befriedigt?

Das ist doch eine häufige Aufgabe von Paketen Und in dem Paket steckt ja wie geschrieben mehr als nur der SysV-Init-Ersatz.

Debianpakete bestehen ja ganz platt gesagt aus zwei Teilen:
1. Die eigentlichen Binaries, Scripts, Configs etc. die ich mir auch an der Paketverwaltung vorbei auf die Platte schaufeln kann um die gleiche Funktionalität zu erhalten.
2. Die Verwaltungsinfos im DEBIAN-Verzeichnis für den Paketmanager.

Ich bezog mich hier auf den zweiten Teil. Wenn systemd nur instaliert wird um die Verwaltung zufriedenzustellen, ohne aber wirklich aktiv am System mitzuarbeiten fände ich das hässlich.
Dass da mehr als ein Init-System drin steckt und es diese Aufgaben weiter übernimmt auch wenn ein anderes Init-System genutzt wird macht die Sache eigentlich eher schlimmer als besser, denn dann kann man sich ja gar nicht mehr gegen den Einsatz von Systemd als ganzes entscheiden sondern hat nur noch die Wahl ob es auch als Init-System dienen soll oder nicht.

[cosmac]

lxsession stellt ein grafisches Logout mittels lxsession-logout bereit. Damit das funktioniert braucht es das rec:upower und dessen rec:policykit-1. Letzteres wiederum hängt von libpam-systemd ab, was seinerseits von systemd abhängt.

Aber das sind doch alles keine harten Abhängigkeiten (oder was bedeutet "rec:"?), d.h. upower funktioniert auch ohne policykit. Und lxsession funktioniert auch ohne upower. Und der Desktop funktioniert auch ohne lxsession.

Zusamengefasst lässt sich also sagen, dass ein LXDE-Desktop unter Jessie nicht mehr ohne Systemd betrieben werden kann. Ist das einen Bugreport wert?

sicher nicht, der Desktop kann ja ganz nach Bedarf z.B. mit upower aber ohne policykit betrieben werden. Oder was verstehe ich da falsch?

[hikaru]

Ja, "rec:" bedeutet hier Recommends, wie bei den Paketbeschreibungen. Ich fand es zu lang das auszuschreiben.

d.h. upower funktioniert auch ohne policykit. Und lxsession funktioniert auch ohne upower. Und der Desktop funktioniert auch ohne lxsession.

Ja, aber das lxsession-logout-Fenster kommt nur hoch wenn upower und policykit installiert sind. Ohne diese Pakete ist es also von LXDE aus grafisch weder möglich sich abzmelden, noch den Rechner herunterzufahren oder neuzustarten. Das wird insbesondere dann interessant wenn der User nicht das root-Passwort kennt um diese Aktionen aus einem Terminal heraus auszuführen.

Demzufolge würde ich schon sagen, dass dies die Nutzbarkeit des gesamten Desktops in Frage stellt (wenn auch nicht negiert), ohne dass es jedoch einen RC-Bugreport rechtfertigen würde.


*) mMn ein wesentlicher Aspekt eines GUI

[segmentationfault]

Hallo,

das gleiche Thema habe ich aktuell auch mit Stretch und sysVinit unter Ausschluss von systemd aufgrund meines Problems hier: viewtopic.php?f=12&t=163183

Da ich der Paketverwaltung mitgegeben habe systemd und davon abhängige Pakete nie zu installieren kann ich folglich auch policykit1 nicht installieren und die Folge ist, daß in meinem Fall unter XFCE 4.12 das Neustarten und Runterfahren als normaler Benutzer nicht möglich ist.

Das Paket systemd-shim ist trotzdem in Version 9.1 installiert weil ich das System ausgehend von einem regulärem Jessie mit systemd 215-17 eingerichtet hatte und dann eingestellt hatte systemd zu entfernen und nie zu aktualisieren. Dabei wurde das Paket Systemd-shim nicht entfernt/ konnte nicht entfernt werden.

Da behelfe ich mir halt per Konsole mit root-Rechten und "Shutdown -h now" oder fürs Neustarten mit "Shutdown -r now". Das ist immer noch das kleinere Übel als das andere Problem.

Gruß
segmentationfault

[rendegast]

Da behelfe ich mir halt per Konsole mit root-Rechten und "Shutdown -h now" oder fürs Neustarten mit "Shutdown -r now". Das ist immer noch das kleinere Übel als das andere Problem.

Die Maintainer wollen/müssen aber erreichen, daß ein 08/15-Benutzer in seinem Start-Menü nach Klicken auf Ausschalten/Herunterfahren die erwartete Reaktion bekommt
ohne nachbasteln zu müssen.

[segmentationfault]

Hallo,

wie oben schon von Hikaru angedeutet wäre es ein Segen wenn policykit1 nicht mehr von systemd abhängig wäre.

Dann hätte man auch mit sysVinit eine Chance als normaler Benutzer zu agieren wie bei einer regulären Installation von Jessie/stretch/sid, bei der systemd automatisch eingerichtet wird.

Gruß
segmentationfault

[KP97]

Du kannst das Neustarten bzw. Herunterfahren auch auf eine globale Taste legen.
Dazu braucht es kein policykit und Du mußt nicht immer eine Konsole starten.
Falls gksu nicht installiert ist, nachinstallieren. Dann in den Einstellungen:
Tastatur > Tastaturkürzel .... > Button hinzufügen
z.B.
gksu shutdown -h now
gksu reboot
und eine Taste auswählen. Wenn eine Befehlskette ausgeführt werden soll, muß diese in Hochkommata stehen. Denke daran, daß die Tasten an dieser Stelle global sind, also mit Überlegung wählen.
Ich setze natürlich auf Sid systemd ein, da sehen meine Befehle anders aus. Hier ein Beispiel:

gksu '/bin/systemctl --force poweroff' (Tastenkürzel ist Alt+3, das ist nicht anderweitig belegt)
gksu '/bin/systemctl --force reboot' (Tastenkürzel ist Alt+9)

Das funktioniert ganz hervorragend, selbst wenn man noch ein Script ausführen will. Einfach den Pfad zum Script eintragen, den Rest "macht die Taste".

[guennid]

Bei mir macht sowas schon seit 14 Jahren ein super-Kommando im panel. Ich habe auch keine DE und keinen Login-Manager.

[segmentationfault]

Hallo KP97,

danke für den Tip!
Das funktioniert ganz gut und ist besser als meine Variante bisher.

Allerdings hat rendegast schon recht und es sollte generell auch über den bekannten Weg funktionieren wobei es bei allen Leuten, die eben nicht mit systemd ein Problem haben das ja auch funktioniert nur eben nicht mit der Ausweichlösung sysvinit.

Gruß
segmentationfault

[segmentationfault]

Hallo guennid,

auch Dir vielen Dank! Das probiere ich auch gleich aus.

Gruß
segmentationfault

[guennid]

Überleg's dir! Es ist halt schon, um mit rendegast zu sprechen, ein wenig Gebastel.

Übrigens: Ist allen Beteiligten klar, dass hier ein über zwei Jahre alter Thread aus der Versenkung geholt wurde?