Fehler beim Erstellen des Proxys für
org.gnome.Terminal:/org/gnome/Terminal/Factory0:Die Verbindung ist
geschlossen

Wenn ich versuche, das Terminal mit dbus-launch gnome-terminal zu starten dann funktioniert es.

Was verhindert das gnome-terminal Befehl zum Starten des Terminals als root? Und ist dbus-launch eine akzeptable Problemumgehung oder verursacht wahrscheinlich unvorhergesehene Probleme (ich verstehe nicht wirklich, was es tut)?

Akzeptierte Antwort:

Denken Sie daran, wie Windows-Anwendungen hauptsächlich in den Win16-Tagen funktionierten, bevor Win32 auftauchte und es abschaffte:wo es hInstance gab und hPrevInstance , der Versuch, eine zweite Instanz vieler Anwendungen auszuführen, übergab die Dinge einfach an die erste Instanz, und dies erschwerte die Dinge für Befehlsskripting-Tools (wie Take Command), da eine Anwendung ein zweites Mal aufgerufen wurde und sie sichtbar auf der vorhanden war screen als hinzugefügtes Fenster angezeigt, aber soweit es den Befehlsinterpreter betraf, wurde der untergeordnete Prozess, den er gerade ausgeführt hatte, sofort beendet?

Nun, GNOME hat das Win16-Verhalten für Linux zurückgebracht.

GNOME Terminal ist jetzt eine Client-Server-Anwendung. Das gnome-terminal Das Programm ist nur ein Client, der Desktop-Bus-Nachrichten an einen Server erstellt, seine Befehlszeilenoptionen, seine Umgebung, sein Arbeitsverzeichnis und seine Argumente weitergibt und sich dann einfach beendet. Der Server ist gnome-terminal-server die sich als org.gnome.Terminal registriert auf dem Desktop-Bus und der für die gesamte eigentliche Terminalemulation und die Anzeige des/der Fenster(s) auf der/den GUI(s) verantwortlich ist.

Ein Desktop Bus-Client wie gnome-terminal lokalisiert den Desktop-Bus-Broker über eine Umgebungsvariable, die normalerweise auf Sockets in einem Benutzerverzeichnis wie /run/user/1001 zeigt . Alternativ gibt die Umgebungsvariable an, im „Laufzeitverzeichnis des aktuellen Benutzers“ zu suchen, und ein Pfad ähnlich dem oben genannten wird aus der effektiven Benutzer-ID des Client-Prozesses erstellt. Dieses Verzeichnis ist in beiden Fällen normalerweise privat für den einzelnen Benutzer und für andere (nicht privilegierte) Benutzer unzugänglich.

Heiterkeit entsteht, wenn Leute versuchen, gnome-terminal auszuführen als anderer Benutzer über sudo und dergleichen. Wenn die Umgebungsvariable auf ein explizit benanntes Laufzeitverzeichnis zeigt, kann ein nicht privilegierter Client keine Verbindung zum benutzerspezifischen Desktop-Bus herstellen. Wenn die Umgebungsvariable auf das Laufzeitverzeichnis „des aktuellen Benutzers“ zeigt, sucht sie nach dem falschen Desktop-Bus-Broker, häufig nach dem für einen Benutzer, der derzeit keinen hat ein Desktop Bus-Broker, der ausgeführt wird, weil sich der Benutzer nicht angemeldet und die benutzerspezifischen Dienste dieses Benutzerkontos nicht gestartet hat. (Desktop-Bus-Broker pro Benutzer werden von einem Service-Manager pro Benutzer ausgeführt. Der Service-Manager pro Benutzer wird entweder explizit gestartet oder, im Fall einiger Service-Management-Software, durch einige ziemlich hässliche Haken in den Benutzerauthentifizierungsprozess, der von verwendet wird wie das login , su , und SSH-Serverprogramme.)

Der Grund für dbus-launch Für Sie als Superuser hat dieser dbus-launch funktioniert explizit einen anderen Desktop-Bus-Broker gestartet, der als Superuser ausgeführt wird, der gnome-terminal sprechen konnte. Glücklicherweise war das System auch so konfiguriert, dass es den gnome-terminal-server bei Bedarf startete Server, wenn der Client versucht hat, sich über den Broker mit ihm zu verbinden. (Dies ist nicht unbedingt der Fall, und heutzutage wird ein solches Demand-Starting als minderwertiger Mechanismus angesehen, da es dazu führt, dass viele Desktop Bus-Serverprozesse unter keiner Art von Service-Management ausgeführt werden. In der Tat, ohne den Broker selbst unter Dienstverwaltung wird ebenfalls als minderwertig angesehen und wird im Allgemeinen auch nicht als gute Idee für den Superuser angesehen Konto, um diese Art von Diensten auszuführen, da viele von ihnen nicht erwarten, mit Superuser-Rechten ausgeführt zu werden, da sie davon ausgehen, dass sie unter den Ägiden gewöhnlicher Benutzerkonten ausgeführt werden.)

Weitere Heiterkeit entsteht, wenn, wie der Fragesteller bei „Wie kann ich gnome-terminal remote auf meinem Headless-Server starten? (fails to launch over X11 forwarding)“ versucht, gnome-terminal auszuführen wenn nicht einmal der ursprüngliche Benutzer einen Desktop-Bus-Broker ausgeführt hat. Dies passiert beispielsweise, wenn man sich über SSH angemeldet hat, aber der SSH-Anmeldeprozess den benutzerbezogenen Service-Manager nicht startet, was wiederum bedeutet, dass der benutzerbezogene Desktop-Bus-Broker nicht ausgeführt wird, und der gnome-terminal-server Server kann nicht über einen Desktop-Bus erreicht werden. (Je nachdem, wie das System konfiguriert ist, könnte die grafische Anmeldung immer noch das Starten des Dienstmanagers pro Benutzer auslösen, und daher könnte man beobachten, dass die grafische Anmeldung als derselbe Benutzer die Dinge auf magische Weise zum Laufen bringt. Und wieder dbus-launch würde explizit einen nicht vom Dienst verwalteten Desktop-Bus-Broker starten.)

Noch mehr Heiterkeit ergibt sich, wenn einer der Service-Manager die Hooks in login hat , su , und der SSH-Server. Diese Hooks implementieren normalerweise die Semantik zum Starten der Dienstverwaltung pro Benutzer und aller damit gestarteten Dienste pro Benutzer bei der ersten Anmeldung für diesen Benutzer. und stoppen Sie sie alle, um sich für diesen Benutzer abzumelden. Wenn man viele kurzlebige und sich nicht überschneidende SSH-Sitzungen hat, kann viel Overhead entstehen, wenn das gesamte Dienstverwaltungssystem pro Benutzer (und alle seine Autostart-Dienste) nutzlos gestartet und heruntergefahren werden Beginn und Ende jeder dieser SSH-Sitzungen. systemd, einer dieser Dienstmanager, hat einen unvollkommenen „Linger“-Mechanismus, der dies nur halbwegs angeht. Dies bedeutet, dass die Dienstverwaltung pro Benutzer nach der endgültigen Abmeldung „verweilt“, aber nicht verhindert, dass die Dienstverwaltung pro Benutzer überhaupt gestartet wird.

Weiterführende Literatur

• Jonathan de Boyne Pollard (2016). /run/user/jim/dbus . „Gazetter“. Nosh-Leitfaden . Software. jdebp.eu.
• Jonathan de Boyne Pollard (2016). „Benutzerbezogene Dienste“. Nosh-Leitfaden . Software. jdebp.eu.
• Führen Sie echte mehrere Prozessinstanzen von gnome-terminal aus
• Systemd-Dienst des Benutzers persistent machen
• https://unix.stackexchange.com/a/323700/5132