https://github.com/TurboVNC/turbovnc/commit/32dd16ff2fe4fce8f2b36f635b0e53c693a1a33d adds an undocumented environment variable (TVNC_SHAREDDBUS) that, when set to 1, will cause the TurboVNC session to use the shared (systemd-provided) D-Bus session bus instance rather than a unique D-Bus session bus instance. Using the shared D-Bus session bus instance should fix all of the incompatibilities with cgroup v2, with the understanding that only one session (including TurboVNC sessions and local sessions) can simultaneously use the shared D-Bus session bus instance. At the moment, TVNC_SHAREDDBUS is mainly for testing purposes. I realize that you solved the issue another way. I am just adding to the thread in case someone else discovers it from Google.
On Tuesday, January 16, 2024 at 2:50:11 PM UTC-5 torsten wrote: > Hi again, > > replacing the firefox snap version by the apt (ESR) version of firefox > was fully successful. I used a mix composed of the steps recommended in > > https://askubuntu.com/questions/1399383/how-to-install-firefox-as-a-traditional-deb-package-without-snap-in-ubuntu-22. > > > Firstly firefox disappeared completely after installing it. But after a > reboot it was back, and also available as icon inside the TVNC session. > Many thanks for your help, DRC! > > BR > > tkansgar > > Am 10.01.2024 um 22:48 schrieb Torsten Kupke: > > So for my case I understand, I either can have a local session and a > > parallel TVNC session, which I can connect to from the local one, or I > > can start the snap version of firefox by icon inside the TVNC session, > > but not both. So I have to replace the firefox snap version by the apt > > version. That's annoying! But I know, you're not responsible for this. > > Many thanks, DRC, for your very insightful explanation! > > > > Am 09.01.2024 um 20:08 schrieb 'DRC' via TurboVNC User > > Discussion/Support: > >> No, if a running TurboVNC session is using the shared > >> (systemd-provided) D-Bus session bus instance, then attempting to log > >> in locally or start another VNC session that uses the shared D-Bus > >> session bus instance will fail, and it may even cause the window > >> manager in the existing TurboVNC session to crash. (Have I mentioned > >> how much I hate systemd?) That is the tradeoff. If you want > >> TurboVNC to work with snap applications "out of the box" (with no > >> workarounds), then you have to sacrifice the ability to run multiple > >> simultaneous sessions. You can't run multiple simultaneous sessions > >> unless you use an independent D-Bus session bus instance for each, > >> but you can't run confined snap applications unless you use the > >> shared D-Bus session bus instance. > >> > >> On 1/9/24 12:14 PM, Torsten Kupke wrote: > >>> Wow, that was very detailed and insightful! Before you introduce the > >>> new option, please let me first test, what you described in point 3. > >>> I'm very curious to see, if that helps in my case. But please be > >>> patient, it will take a while. > >>> > >>> But I see a problem, if I do that: > >>> > >>> > but it would also prevent you from starting multiple TurboVNC > >>> sessions (or a TurboVNC session and a local session) > >>> > >>> What would happen with an existing TurboVNC session (I normally > >>> connect to from my home office PC), and I come to the physical > >>> machine and login there locally under my username? Would I be able > >>> to start the local desktop? And would I be able to connect to the > >>> existing TurboVNC session by using the locally installed TurboVNC > >>> viewer? > >>> > >>> Am 08.01.2024 um 20:17 schrieb 'DRC' via TurboVNC User > >>> Discussion/Support: > >>>> You will see those same warning messages if you start Firefox from > >>>> the command line in a local session. The only reason you don't > >>>> normally see them is that you normally start Firefox from the > >>>> icon. You will find that both Firefox and Chrome spew a lot of > >>>> command-line warnings such as those, regardless of platform. > >>>> However, in this case, the warning messages appear to be a result > >>>> of how Firefox is deployed as a snap application. Snap > >>>> applications are deployed with all of their dependencies > >>>> self-contained, which is not the typical way in which Linux > >>>> applications are deployed. In fact, the snap back end is > >>>> proprietary, so snaps only exist on Ubuntu. Snaps are essentially > >>>> a closed-source packaging system on top of an open-source O/S, and > >>>> they are somewhat controversial for that reason and others > >>>> ( > https://www.reddit.com/r/linux/comments/j3ajnf/whats_wrong_with_snaps_why_so_many_people_hate_it/ > ). > >>>> > >>>> The core of the issue is that TurboVNC sessions each create an > >>>> independent D-Bus session bus instance. That allows multiple window > >>>> manager instances to co-exist simultaneously under the same user > >>>> account. However, apparently the snap system expects to use the > >>>> systemd-provided D-Bus session bus instance. (More specifically, > >>>> this is the case with confined snaps. Unconfined snaps should work > >>>> as expected with TurboVNC.) If you google "is not a snap cgroup" > >>>> and "dbus_session_bus_address", you'll see that this issue is not > >>>> specific to TurboVNC. It exists with all multi-session Linux > >>>> remote desktop software (X2Go, etc.), because all multi-session > >>>> Linux remote desktop software similarly creates an independent > >>>> D-Bus session bus instance for each remote desktop session. You > >>>> can, in fact, reproduce the issue in a local session by starting > >>>> firefox with: > >>>> > >>>> dbus-launch --sh-syntax --exit-with-session firefox > >>>> > >>>> I really believe that this is a limitation of the snap system. If > >>>> confined snaps fundamentally cannot work with an independent D-Bus > >>>> session bus instance, then the snap system should ignore > >>>> DBUS_SESSION_BUS_ADDRESS when launching such applications. But > >>>> since snap is a proprietary technology, good luck getting any > >>>> movement on that. > >>>> > >>>> There are several ways to work around the issue: > >>>> > >>>> 1. The most non-intrusive way is to unset DBUS_SESSION_BUS_ADDRESS > >>>> when starting snap applications in a TurboVNC session. That forces > >>>> the applications to use the systemd-provided D-Bus session bus > >>>> instance rather than the D-Bus session bus instance associated with > >>>> the TurboVNC session. That means that you will be limited to one > >>>> simultaneous instance of each application, but Firefox aggressively > >>>> disallows more than one simultaneous instance of itself anyhow. > >>>> > >>>> 2. TigerVNC takes a different approach to launching VNC sessions, > >>>> using systemd rather than a vncserver script. Their approach is > >>>> supposedly more systemd-friendly and doesn't experience this > >>>> specific issue with snap applications. However, in my testing, > >>>> their approach has other issues. On Ubuntu 22.04 specifically, > >>>> TigerVNC sessions launched using the latest official TigerVNC > >>>> binaries do not display the GNOME 3 GUI properly. (They just show > >>>> a blank desktop with no sidebar or taskbar, and the window > >>>> decorations are incorrect.) Also, in my testing, sessions started > >>>> in that manner sometimes immediately crash on Ubuntu 22.04. I > >>>> could adopt TigerVNC's approach as an optional means of starting > >>>> TurboVNC sessions (replacing the current init.d method of starting > >>>> TurboVNC sessions, which is a poorly-documented and rarely-used > >>>> legacy of TightVNC.) However, that would take a lot of effort, in > >>>> part because I would want to document and test it more thoroughly > >>>> than TigerVNC apparently has. At the moment, I'm not convinced > >>>> that starting sessions with systemd has any advantages other than > >>>> addressing this specific issue, and there are less intrusive ways > >>>> of addressing this issue. > >>>> > >>>> 3. I could add a vncserver/turbovncserver.conf option that causes > >>>> the TurboVNC session to forego creating an independent D-Bus > >>>> session bus instance. (That is the main reason why TigerVNC > >>>> doesn't experience this issue.) That would effectively fix this > >>>> issue on a per-session basis, but it would also prevent you from > >>>> starting multiple TurboVNC sessions (or a TurboVNC session and a > >>>> local session) simultaneously under the same user account > >>>> (essentially the same limitations as TigerVNC.) Note that you can > >>>> already achieve the same effect by copying > >>>> /opt/TurboVNC/bin/xstartup.turbovnc to ~/.vnc, editing > >>>> ~/.vnc/xstartup.turbovnc and commenting out all of the dbus-launch > >>>> stuff, and setting $xstartup = "$vncUserDir/xstartup.turbovnc" in > >>>> ~/.vnc/turbovncserver.conf. > >>>> > >>>> If you ask me, the nicest approach is just to acknowledge that snap > >>>> applications are the problem and work around the problem only for > >>>> those applications-- or not use snap applications at all, or use > >>>> Chrome like 65% of the people surfing the web do. The alternative > >>>> is to artificially limit the TurboVNC infrastructure for the sole > >>>> purpose of supporting a proprietary application deployment system > >>>> whose authors couldn't be bothered to test their system with > >>>> multi-session remote desktop software. > >>>> > >>>> I am more than happy to implement Item 3 above if that would make > >>>> you happy. I can't think of anything else that I can realistically > >>>> do to address this at the moment. (Item 2 would take a lot longer > >>>> and would probably require some funding.) Hopefully the tome above > >>>> explains why I can't just wave a magic wand and make TurboVNC > >>>> behave in all cases like a local session. Even if TurboVNC > >>>> severely sacrificed functionality, as TigerVNC has done, it still > >>>> wouldn't behave in all cases like a local session. Developing > >>>> TurboVNC is really difficult, because I have to hit multiple moving > >>>> targets across multiple distributions and operating systems. I do > >>>> the best I can with a very limited budget and a development team > >>>> consisting only of me. > >>>> > >>>> DRC > >>>> > >>>> On 1/8/24 3:47 AM, Torsten Kupke wrote: > >>>>> Hi DRC, > >>>>> > >>>>> starting firefox from the command line, like you proposed, works. > >>>>> But I get some messages, I don't know, how to assess: > >>>>> > >>>>> $ DBUS_SESSION_BUS_ADDRESS= firefox > >>>>> Gtk-Message: 09:15:57.854: Failed to load module "xapp-gtk3-module" > >>>>> Gtk-Message: 09:15:57.854: Not loading module "atk-bridge": The > >>>>> functionality is provided by GTK natively. Please try to not load it. > >>>>> [378359, Main Thread] WARNING: GTK+ module > >>>>> > /snap/firefox/3600/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so > > > >>>>> cannot be loaded. > >>>>> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same > >>>>> process is not supported.: 'glib warning', file > >>>>> /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:187 > >>>>> > >>>>> (firefox:378359): Gtk-WARNING **: 09:15:57.926: GTK+ module > >>>>> > /snap/firefox/3600/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so > > > >>>>> cannot be loaded. > >>>>> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same > >>>>> process is not supported. > >>>>> Gtk-Message: 09:15:57.926: Failed to load module > >>>>> "canberra-gtk-module" > >>>>> [378359, Main Thread] WARNING: GTK+ module > >>>>> > /snap/firefox/3600/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so > > > >>>>> cannot be loaded. > >>>>> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same > >>>>> process is not supported.: 'glib warning', file > >>>>> /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:187 > >>>>> > >>>>> (firefox:378359): Gtk-WARNING **: 09:15:57.928: GTK+ module > >>>>> > /snap/firefox/3600/gnome-platform/usr/lib/gtk-2.0/modules/libcanberra-gtk-module.so > > > >>>>> cannot be loaded. > >>>>> GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same > >>>>> process is not supported. > >>>>> Gtk-Message: 09:15:57.928: Failed to load module > >>>>> "canberra-gtk-module" > >>>>> > >>>>> But starting firefox this way is an emergency solution in my eyes. > >>>>> Are you sure, that it's not possible to make the snap version of > >>>>> firefox startable via icon inside the TVNC session, like any other > >>>>> regular application? > >>>>> > >>>>> Uninstalling the snap version of firefox and reinstalling it > >>>>> through apt seems to be a bit difficult and error-prone. There are > >>>>> many different recommendations in the web, which steps should be > >>>>> done therefore to make firefox working properly, when installing > >>>>> with apt on Ubuntu 22.04. Currently I'm unsure, which of those I > >>>>> should consider or not. Finding a proper one will take some time. > >>>>> I would have to see, when I will find that time. > >>>>> > >>>>> BR > >>>>> > >>>>> tkansgar > >>>>> > >>>>> Am 05.01.2024 um 19:31 schrieb 'DRC' via TurboVNC User > >>>>> Discussion/Support: > >>>>>> My suggestion regarding dbus-x11 was to Felix and was pertaining > >>>>>> to a different issue. > >>>>>> > >>>>>> Try unsetting DBUS_SESSION_BUS_ADDRESS, e.g.: > >>>>>> > >>>>>> $ DBUS_SESSION_BUS_ADDRESS= firefox > >>>>>> > >>>>>> That works for me. Apparently this is a known issue with snap > >>>>>> applications running in VNC: > >>>>>> > >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1767183 > >>>>>> > https://askubuntu.com/questions/1452155/how-can-i-get-snap-applications-to-run-in-vnc-session > > >>>>>> > >>>>>> > >>>>>> You can work around it by uninstalling the snap version of > >>>>>> Firefox and reinstalling Firefox using APT. > >>>>>> > >>>>>> > >>>>>> On 1/5/24 11:47 AM, Torsten Kupke wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I'm not sure, whether this has been asked here already. Since > >>>>>>> upgrading Ubuntu from 18.04 to 22.04 and TurboVNC from 2.2.7 to > >>>>>>> 3.1 I'm unable to use firefox inside the TVNC session. The > >>>>>>> firefox icon is not visible in the dock on the left side and in > >>>>>>> the list of startable applications. But it is definitely > >>>>>>> installed on that machine. And when I sit locally in front of > >>>>>>> it, firefox is present in the dock outside of the TVNC session > >>>>>>> and startable. When I try to start it inside from a terminal > >>>>>>> shell, I get this: > >>>>>>> > >>>>>>> $ firefox > >>>>>>> /user.slice/user-700.slice/session-c2.scope is not a snap cgroup > >>>>>>> > >>>>>>> I googled this and found several solution proposals. But they > >>>>>>> all look strange to me (maybe because I'm no Linux nerd). Can > >>>>>>> anyone tell me, what's the correct and best solution to make > >>>>>>> firefox startable inside the TVNC session again? By the way, > >>>>>>> dbus-x11 cannot be the reason, since it is installed already. > >>>>>>> > >>>>>>> BR > >>>>>>> > >>>>>>> tkansgar > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/d85f3cb5-7283-41e3-8221-44fa6832c534n%40googlegroups.com.
