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 turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/f298631d-991a-9b02-bd86-abda8591326e%40virtualgl.org.
