firefox not startable inside the TurboVNC session

[Torsten Kupke]

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

[DRC]

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.

[Torsten Kupke]

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

[DRC]

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

[Torsten Kupke]

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?

[DRC]

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.

[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!

[Torsten Kupke]

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

[DRC]

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.