Possible explanations:
1. If the TurboVNC session is using Display :1, then you're probably
running into this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1673793
Basically, if WaylandEnable=false, GDM stomps on Display :1 when you log
in locally. It doesn't bother to check whether anything else is
currently using Display :1. Newer versions of GDM seem to care more
about the abstract socket associated with the X display than the Unix
domain socket under /tmp/.X11-unix. Thus, I am investigating whether
TurboVNC can listen on an abstract socket, with the hope that this will
prevent GDM from stomping on TurboVNC's display.
https://github.com/TurboVNC/turbovnc/commit/f2a575f07623026e9212fd3f963695f2b79c270a,
which I pushed earlier this week, makes TurboVNC's vncserver script
check for an in-use abstract socket before declaring that a display
number is available. This prevents TurboVNC from stomping on GDM if GDM
is using Display :1 and /tmp/.X11-unix/X1 is accidentally deleted.
If that is the cause of the issue, then forcing the TurboVNC session to
use :2 (by passing :2 to /opt/TurboVNC/bin/vncserver) is an effective
workaround.
2. If you are using VirtualGL to run the window manager in the TurboVNC
session (by passing -vgl to /opt/TurboVNC/bin/vncserver or setting
$useVGL in turbovncserver.conf), then it is expected that VirtualGL will
be disrupted if you log in/log out locally. That is because, when
WaylandEnable=false, GDM uses Display :0 for the greeter and Display :1
for the session. If VirtualGL is expecting to use Display :0 as a 3D X
server (which it does by default), then the 3D X server will go away
from its point of view as soon as you log in.
3. You may not have the dbus-x11 package installed. The TurboVNC .deb
packages now require dbus-x11 as a dependency, but that change landed
after the TurboVNC 3.1 release. If dbus-x11 is not installed, then
TurboVNC sessions will try to use the same D-Bus session as local
logins, so there will be conflicts such as what you describe.
On 1/4/24 9:58 AM, Felix Natter wrote:
Dear turbovnc experts,
if I start a (turbo-)vnc server and then log out the physical session,
the VNC session is terminated as well (or broken). I think this is a
limitation of (turbo-)vnc? It does work with CentOS7.
In order to work around this, I create the (turbo-)vnc server
in a (localhost) ssh session to the target host (is there a better
solution?) ;-)
This hack seems to work (I can still use the VNC session even if the
physical session is logged out).
However, it seems that in this specific situation, when locking a
vnc session (automatic or manual), the login manager does not
accept my password for unlocking the session (it is stuck).
I cannot unlock the session by running "loginctl unlock-session" from
an ssh connection.
I am using TurboVNC 3.1 on Ubuntu22.04 (Standard GNOME with gdm3).
I am using virtualgl so WaylandEnable=false is set in
/etc/gdm3/custom.conf.
Is it true that logging out of the physical session (where the
VNC session was created) is not supported at all (on Ubuntu22)?
Many Thanks and Best Regards!
Felix
--
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/22506e22-5e4f-455e-92fd-973019316e59n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/22506e22-5e4f-455e-92fd-973019316e59n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/2f5be9af-49a6-929b-12ab-3d477fc8bb9b%40virtualgl.org.
