To be clear, when I talked about starting a session from SSH, I meant
connecting directly to the system using SSH, not doing 'ssh localhost'
from the local session. However, I'm not sure if that matters.
The value of XDG_SESSION_TYPE should always be x11 in a TurboVNC
session, so I suspect that you recorded the environment variables too
early. The only difference that matters is the difference between the
environment variables inside of a TurboVNC session that fails vs. a
TurboVNC session that succeeds. Please record the environment variables
inside of the TurboVNC sessions and pipe them through 'sort' before
diffing them. It would also be more meaningful to compare a failing vs.
successful configuration using the same window manager, i.e. the
difference between TurboVNC/GNOME sessions that succeed vs. fail and the
difference between TurboVNC/MATE sessions that succeed vs. fail.
On 1/20/24 2:59 AM, Felix Natter wrote:
hello DRC,
since I get a different error when starting the vnc session from an
ssh localhost session,
I recorded different environments and made diffs (attached). Can you
tell something
other than $XAUTHORITY?
Many Thanks and Best Regards!
Felix
Felix Natter schrieb am Samstag, 20. Januar 2024 um 07:36:09 UTC+1:
hello DRC,
unfortunately, the problem still occurs without $XAUTHORITY.
This morning I was only able to test with a VM, would it make a
difference?
Many Thanks and Best Regards!
Felix
DRC schrieb am Freitag, 19. Januar 2024 um 21:28:25 UTC+1:
I still can't reliably reproduce the issue on my machine, but
I am suspicious that it might have something to do with the
XAUTHORITY environment variable. In a local session,
XAUTHORITY is set to /run/user/501/gdm/Xauthority. If
XAUTHORITY is set, then vncserver instructs Xvnc to use that X
authority file, and it wouldn't surprise me if GDM does
something to that file when you log out. Can you try the
following when launching a TurboVNC session from the local
session?
unset XAUTHORITY
/opt/TurboVNC/bin/vncserver
That should simulate what happens in an SSH session. If that
resolves the issue, then vncserver probably just needs to
ignore XAUTHORITY.
This would also explain why you don't see the problem with
lightdm. lightdm sets XAUTHORITY to ~/.Xauthority, which is
the traditional X authority location that doesn't rely upon
systemd.
--
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/4b460df9-b5e4-41a1-80bf-62fb4dd0dd98n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/4b460df9-b5e4-41a1-80bf-62fb4dd0dd98n%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/17c86df1-ba34-42ff-ac6f-81262b2a84cb%40virtualgl.org.
