%20.png)
Snap-Apps in Ubuntu geben beim Starten in virtuellen Nomachine-Desktops oder x2go einen Fehler aus und werden nicht ausgeführt. Dies gilt nur für eingeschränkte Snaps, was auf die meisten zutrifft.
Virtuelle Desktops von nomachine sind mit dem nomachine Workstation Server oder anderen Produkten im Terminalserver-Stil verknüpft, nicht mit dem grundlegenden Desktop-Sharing-Client von nomachine. Ich verwende x2go nicht, aber Benutzer berichten von identischen Problemen, daher gehe ich davon aus, dass auch hier ein virtueller Desktop geteilt wird.
Die bekannten Workarounds bestehen darin, entweder das Snap-Sandboxing durch Deaktivieren von cgroups v2 zu ändern oder den normalen Wert von DBUS_SESSION_BUS_ADDRESS manuell zu simulieren. Die erste ist einfach, aber dramatisch, da cgroups v2 ein großer Teil der modernen Linux-Erfahrung ist, und die zweite Lösung ist ein Hack, der bei mehreren Benutzern abstürzen kann.
Ich weiß nicht, warum DBUS_SESSION_BUS_ADDRESS falsch ist, wenn nomachine oder x2go die Sitzung starten. Wenn Sie diese Fernzugriffs-Apps verwenden, um auf virtuelle Desktopsitzungen zuzugreifen, gibt es keine Anmeldung, die von einem herkömmlichen Display-Manager verwaltet wird. Nomachine führt die Anmeldung selbst durch und startet dann die grafische Sitzung. Ich gehe davon aus, dass x2go dasselbe tut. Es gibt einige Unterschiede in den Codepfaden, die zu einem unerwarteten Wert für DBUS_SESSION_BUS_ADDRESS führen. Ich vermute, dass ein Teil der Startlogik von systemd-Sitzungen nicht von nomachine oder x2go aufgerufen wird. Aber es war schwer für mich, das zu verstehen. Mir ist klar, dass ich keine Ahnung davon habe, wie die Linux-Anmeldung funktioniert, und ich kann keine Dokumentation finden, die ich verstehe.
(Ich denke, dass eine „Bildschirmfreigabe“-Sitzung, die eine Verbindung zu einer physisch vorhandenen Sitzung herstellt, wie etwa dem Nomachine-Desktop, dieses Problem nicht hat, da sie den Display-Manager nicht umgeht.)
Ich habe Erfahrung mit Nomachine, aber x2go-Benutzer melden dasselbe Problem und der gleiche Workaround funktioniert auch dort.
Mit einem virtuellen Nomachine-Desktop in Xubuntu oder Ubuntu kann ich keine eingeschränkten Snaps wie Firefox starten (es sei denn, Cgroups v2 ist über einen Kernelparameter deaktiviert).
Der Fehler beim Start von einem Terminal aus sieht folgendermaßen aus:
tim@ubuntu ~/Desktop $ firefox /user.slice/user-1000.slice/session-c3.scope ist keine Snap-Cgroup
aber eine der Hauptursachen des Problems scheint zu sein, dass
DBUS_SESSION_BUS_ADDRESS falsch eingerichtet ist. Es hat zwar einen Wert, aber einen, der sich stark von einer normalen Display-Manager-Sitzung unterscheidet.
Bei einer typischen Ubuntu-Anmeldung sehen wir etwa Folgendes:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
aber in der unterbrochenen Nomachine-Sitzung sehen wir so etwas:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
Wenn ich DBUS_SESSION_BUS_ADDRESS manuell einstelle, funktionieren eingeschränkte Snaps.
Wenn ich beispielsweise in Nomachine xfce wie folgt starte:
DefaultDesktopCommand "env
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus /usr/bin/startxfce4"
Schnappschüsse funktionieren.
Das Problem tritt nur bei eingeschränkten Snaps auf, wenn cgroups v2 ausgeführt wird. Eingeschränkte Snaps und damit Sandbox müssen also ebenfalls ein Faktor sein. Aus diesem Grund sind viele davon überzeugt, dass es sich um einen Snap-Fehler handelt, die Snap-Entwickler jedoch nicht so sehr.
Wenn ich mir den seltsamen Wert für DBUS_SESSION_BUS_ADDRESS ansehe, komme ich zu dem Schluss, dass die Sitzung nicht richtig eingestellt ist. Die Art und Weise, wie nomachine die Sitzung startet, muss sich von der Arbeitsweise der Display-Manager unterscheiden. DBUS_SESSION_BUS_ADDRESS wird im systemd-Anmeldeprozess eingestellt, bevor die grafische Sitzung startet.
Die andere Möglichkeit ist, dass
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
ist ein völlig gültiger Wert, der aber der Sandboxing-Funktion von Snap nicht gefällt (uneingeschränkte Snap-Apps haben kein Problem).
Der am wenigsten aufwändige Workaround besteht darin, cgroups v2 zu deaktivieren. Genau das empfiehlt nomachine.
Warum ist DBUS_SESSION_BUS anders, wenn nomachine oder x2go die Anmeldung durchführen?