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/704f8149-546e-4d60-9382-4efa785f94d2%40t-online.de.
