Ubuntu 22.04: Issues with VNC session if physical session is logged out

[Felix Natter]

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

[DRC]

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.

--
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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/22506e22-5e4f-455e-92fd-973019316e59n%40googlegroups.com.

[DRC]

If in fact the issue is #1, then you can work around it by passing '-listen local' to /opt/TurboVNC/bin/vncserver when starting the TurboVNC session.  Apparently GDM will not stomp on the TurboVNC session's X display number if the TurboVNC session listens on the abstract Unix domain socket associated with its X display number.  By default, TurboVNC only listens on the pathname Unix domain socket (under /tmp/.X11-unix) associated with its X display number, but passing '-listen local' to vncserver causes TurboVNC to listen on the abstract UDS as well.

There are apparently some security concerns regarding abstract Unix domain sockets, so I'm reluctant to enable this by default.  I just wanted to document it as a workaround.

[DRC]

As far as the screen saver not accepting your password, that may be due to this issue:

https://github.com/TurboVNC/turbovnc/issues/238

That is a known issue with GNOME and has to do with the fact that GNOME doesn't fully support multiple sessions.  TurboVNC is able to work around most of the GNOME issues by setting up an independent D-Bus instance for each TurboVNC session, but there are a few lingering issues such as this.  TigerVNC, by contrast, punts on the issue and does not support multiple simultaneous TigerVNC sessions (or a simultaneous TigerVNC and local session) under the same user account.  That is, IMHO, an unnecessary overkill, because plenty of window managers (MATE, Xfce, etc.) work perfectly fine with multiple simultaneous sessions, and we are able to make GNOME work well enough to be usable.

On 1/4/24 9:58 AM, Felix Natter wrote:

[Felix Natter]

Dear DRC,

many thanks for your replies!

regarding 1): I am using :2 (because :1 seems to be used by Ubuntu; if I try to use :1, I get a crashed session dialog)

regarding 2): I have not changed $useVGL in /etc/turbovncserver.conf and I am not using -vgl

shall I try it?

regarding 3): dbus-x11 is installed

regarding https://github.com/TurboVNC/turbovnc/issues/238:
loginctl unlock-session does not work for me.

-list local did not help unfortunately.

Is there *any* workaround for this? I need to log out the physical session, because if I only lock
it, then as soon as the VNC session is unlocked, the physical session is unlocked as well.

How about using export TVNC_WM=2d? which package do I need?
Or can I use MATE/XFCE just for VNC and GNOME3 from the office?

Many Thanks and Best Regards,
Felix

[Felix Natter]

hello DRC,

I found a workaround: Use GNOME3 in the physical session and GNOME-flashback (export TVNC_WM=2d)
in the VNC session. Due to the two different session types, I avoid the problem where an unlock

of the VNC session also unlocks the physical session, so I do not have to log out the physical session :)

[DRC]

On 1/5/24 1:18 AM, Felix Natter wrote:

Dear DRC,

many thanks for your replies!

regarding 1): I am using :2 (because :1 seems to be used by Ubuntu; if I try to use :1, I get a crashed session dialog)

You should be able to work around that by using the latest pre-release build (https://turbovnc.org/DeveloperInfo/PreReleases), which avoids using Display :1 if it detects that the abstract Unix domain socket associated with Display :1 is in use, and passing -listen local to /opt/TurboVNC/bin/vncserver (or setting $serverArgs = "-listen local"; in turbovncserver.conf), which causes the TurboVNC Server to listen on an abstract Unix domain socket (thus preventing GDM from stomping on TurboVNC's display.)  With that configuration, Display :1 will be chosen by either GDM or TurboVNC, depending on which is started first.  The other will choose Display :2.  Note that there are some articles out there that caution against the security ramifications of abstract Unix domain sockets, but I can't find any evidence that they are definitively less safe than the world-readable pathname Unix domain sockets under /tmp/.X11-unix.  I am still investigating that and may decide to enable -listen local by default in a future TurboVNC release, as Xorg does.

regarding 2): I have not changed $useVGL in /etc/turbovncserver.conf and I am not using -vgl

shall I try it?

No.  Running the window manager with VirtualGL could have been the cause of the problem, but it won't fix the problem.

regarding 3): dbus-x11 is installed

I see now that it was you who reported the issue caused by the lack of a dbus-x11 dependency, so I apologize for that noise.

regarding https://github.com/TurboVNC/turbovnc/issues/238:
loginctl unlock-session does not work for me.

You didn't read far enough.  See:

https://github.com/TurboVNC/turbovnc/issues/238#issuecomment-739065121

-list local did not help unfortunately.

-listen local, not -list local.  See above.  It will prevent GDM from stomping on TurboVNC's display, but that wasn't apparently the cause of the issue.

> I found a workaround: Use GNOME3 in the physical session and GNOME-flashback (export TVNC_WM=2d)
> in the VNC session. Due to the two different session types, I avoid the problem where an unlock

> of the VNC session also unlocks the physical session, so I do not have to log out the physical session :)

I am still unable to reproduce the issue, and I can't imagine why running the Flashback session would matter.  Flashback just puts a GNOME 2-style GUI on top of the GNOME 3 shell.  It's still GNOME 3 under the hood.  I would love to figure out why the issue is occurring on your system, because it might reveal a deficiency in TurboVNC that needs to be addressed.  Any chance you could send me the TurboVNC Server log from a TurboVNC session that was killed whenever you logged out of the local session?

[Felix Natter]

hello DRC,

regarding 1)
ok, I will test "-listen local", but unfortunately, I cannot do this short-term.

> regarding https://github.com/TurboVNC/turbovnc/issues/238:
> loginctl unlock-session does not work for me.

I have another solution for unlocking the session if it is blocked,
but it is annoying since we have the policy to lock the session after 2mins.

> I am still unable to reproduce the issue, and I can't imagine why running the Flashback session would matter.  Flashback just puts a GNOME 2-style GUI on top of the GNOME 3 shell.  It's still GNOME 3 under the

Flashback vs. GNOME3 seems to do things a little differently. I observed that
if I unlock a Flashback VNC session ("HO"), it will not unlock the GNOME3 session ("office"),
which is the bug that I wanted to avoid with this post :)

> hood.  I would love to figure out why the issue is occurring on your system, because it might reveal a deficiency in TurboVNC that needs to be addressed.  Any chance you could send me the TurboVNC Server log >
> from a TurboVNC session that was killed whenever you logged out of the local session?

Here is what I did:

- create server :2 on HOSTNAME
- log out session on HOSTNAME
- connect to HOSTNAME:2 from B (another network: B can access HOSTNAME but
  not the other way around)

Now the VNC session is unusable:

"Could not connect: Verbindungsaufbau abgelehnt. Attempt to reconnect?"

" Verbindungsaufbau abgelehnt" is probably "connection refused".

see hostname.log (probably not of much help).

If I start the server HOSTNAME:2 from a localhost ssh session and log out,

then I can connect to the session, but cannot unlock it when it is locked.

[DRC]

On 1/8/24 12:17 AM, Felix Natter wrote:
> > regarding https://github.com/TurboVNC/turbovnc/issues/238:
> > loginctl unlock-session does not work for me.
>
> I have another solution for unlocking the session if it is blocked,
> but it is annoying since we have the policy to lock the session after
> 2mins.

The method in
https://github.com/TurboVNC/turbovnc/issues/238#issuecomment-739065121
works every time and can be automated.

This issue is a result of GNOME developers not taking into account the
need for multiple simultaneous sessions under the same user account. 
Many large-scale commercial/academic TurboVNC deployments do not use
GNOME for that reason.  In such environments, TurboVNC and VirtualGL are
used instead of a Linux workstation, not as a means of remotely
accessing a Linux workstation.  Users of such systems typically access a
TurboVNC session from a macOS or Windows client, so they have no loyalty
to the GNOME 3 GUI.  Thus, MATE and Xfce are the most common WMs used
with TurboVNC, because they are more lightweight and work well with
multiple simultaneous sessions.  Even if GNOME is used as the TurboVNC
WM, this issue would never occur with a large-scale TurboVNC/VirtualGL
host, because no one would ever log in locally to such a system.  And
since all users of such systems are remote users, it wouldn't make sense
to enable the screen saver at all.

TigerVNC takes a different approach to launching VNC sessions, using
systemd rather than a vncserver script.  Their approach is more
systemd-friendly, but it also has serious limitations: all VNC sessions
must be started by root, VNC display numbers must be statically assigned
to specific users, and only one session (including local sessions and
VNC sessions) can run simultaneously under the same user account.

TurboVNC allows multiple simultaneous sessions under the same user
account, but some window managers don't technically support that, so
there are a few known issues with TurboVNC and GNOME 3:

https://github.com/TurboVNC/turbovnc/issues?q=label%3A%22GNOME%203%22

(Refer also to https://turbovnc.org/Documentation/Compatibility30.)

All of those issues exist with TigerVNC as well, except for
https://github.com/TurboVNC/turbovnc/issues/238.  The only reason that
issue doesn't exist with TigerVNC is that TigerVNC doesn't allow
multiple simultaneous GNOME sessions under the same user account.

I want to support your workflow as best I can.  (I definitely want to
fix the core issue that is the subject of your complaint, the fact that
the TurboVNC session becomes unusable if you log out of the physical
session.  That absolutely should not happen.)  I just feel like I should
provide context for what TurboVNC is and isn't.  It isn't fundamentally
focused on remote access to a single-user workstation.  There are other
remote desktop solutions that are more focused on that workflow, but
none of those solutions allow multiple simultaneous sessions.  If you
want to run a local GNOME session and a VNC GNOME session
simultaneously, there are very few ways to do that, and all of those
ways will encounter the same screen saver issue that you are
encountering with TurboVNC.

> > I am still unable to reproduce the issue, and I can't imagine why
> running the Flashback session would matter.  Flashback just puts a
> GNOME 2-style GUI on top of the GNOME 3 shell.  It's still GNOME 3
> under the
>
> Flashback vs. GNOME3 seems to do things a little differently. I
> observed that
> if I unlock a Flashback VNC session ("HO"), it will not unlock the
> GNOME3 session ("office"),
> which is the bug that I wanted to avoid with this post :)

How are you setting those session names ("HO" and "office")?

> see hostname.log (probably not of much help).
>
> If I start the server HOSTNAME:2 from a localhost ssh session and log out,
> then I can connect to the session, but cannot unlock it when it is locked.

What's odd is that the TurboVNC session log does not show the session
being terminated.  When the session becomes unusable, is the Xvnc
process still running?

[Felix Natter]

hello DRC,

many thanks for your help!

> How are you setting those session names ("HO" and "office")?

These are just descriptions for the computer in the office (vnc server),
and the Home Office computer that is connecting to it (vnc viewer).

> What's odd is that the TurboVNC session log does not show the session
> being terminated.  When the session becomes unusable, is the Xvnc
> process still running?

I think so, but cannot verify at the moment :-/
I will try to reproduce the problem with a VM setup at home on
the weekend.

Would the "primary session logout breaks vnc session" issue" still
occur if I would use Mate for VNC (=Home Office) sessions?
How can I launch a Mate session from a GNOME3 physical session?
Is it
export TVNC_WM=mate
?

[DRC]

On 1/11/24 10:53 AM, Felix Natter wrote:
> Would the "primary session logout breaks vnc session" issue" still
> occur if I would use Mate for VNC (=Home Office) sessions?
> How can I launch a Mate session from a GNOME3 physical session?
> Is it
> export TVNC_WM=mate
> ?

I doubt that the issue would still occur.  The best way to configure
TurboVNC to use MATE persistently is to set

    $wm = "mate";

in ~/.vnc/turbovncserver.conf.  However, you can also temporarily select
MATE by passing

    -wm mate

to /opt/TurboVNC/bin/vncserver when starting the TurboVNC session.

Note that https://turbovnc.org/Documentation/Compatibility30 is the
go-to resource for TurboVNC window manager info.  It lists all of the
window managers that have been tested by me or others in the community,
how to install those WMs, how to select them in TurboVNC, and any known
issues.

This may not be related, but if I comment out WaylandEnable=false in
/etc/gdm3/custom.conf, restart GDM, and log in locally with a
GNOME/Wayland session, I cannot start GNOME in a TurboVNC session.  This
is true regardless of whether I try to start the TurboVNC session from
the GNOME/Wayland session or from a completely separate SSH session. 
When xstartup.turbovnc tries to launch GNOME, GNOME always tries to
direct its display to the Wayland session, even if WAYLAND_DISPLAY is
unset.  I mention this only to point out that there are apparently still
some ways in which a local GNOME session can interfere with a TurboVNC
GNOME session through systemd, even if the two are not sharing a D-Bus
session bus instance.  I am open to any workarounds for that, but I
don't know of any personally-- except using a different WM in TurboVNC
or not trying to use TurboVNC simultaneously with a local login.

[Felix Natter]

hello DRC,

thanks, using MATE and lightdm it works fine (tvnc 3.1.1):

G3   + lightdm + G3 in VNC = bug
mate + lightdm + G3 in VNC = OK
G3   + lightdm + mate in VNC = OK
G3   +     gdm + mate in VNC = bug

The issue is also OK if using :2 without "-listen local".

I also attach a server + client log in the error case

(G3 + gdm + G4 in VNC) in case you have an idea.

Regarding virtualgl: On a box I ran "vglserver_config" before having lightdm installed.
Can I just "unconfigure" and then reconfigure it so that it configures lightdm also?

[DRC]

On 1/11/24 2:35 PM, Felix Natter wrote:
> thanks, using MATE and lightdm it works fine (tvnc 3.1.1):
>
> G3   + lightdm + G3 in VNC = bug
> mate + lightdm + G3 in VNC = OK
> G3   + lightdm + mate in VNC = OK
> G3   +     gdm + mate in VNC = bug
>
> The issue is also OK if using :2 without "-listen local".

In your initial post in this thread, you said you were using TurboVNC
3.1, which did not enable '-listen local' by default. You did not
specify that you were enabling '-listen local', so I was not testing
with that option enabled.  I was able to reproduce the issue once with
'-listen local' enabled, by starting the TurboVNC session from a shell
in the local GNOME session. However, I couldn't reproduce the issue
after that, so it appears to be intermittent at least.  If you can
provide more specifics about how you are starting the TurboVNC session
(and in what order relative to logging in locally), that may help me
reproduce the issue more consistently.  We already know that GDM does a
very poor job of playing nice with other X servers, given that it stomps
on TurboVNC's display if TurboVNC is listening on /tmp/.X11-unix/X1 but
not listening on the equivalent abstract Unix domain socket.  That is,
in fact, the main reason why I started enabling '-listen local' by
default in TurboVNC.  Maybe GDM also does something to interfere with
X11 abstract Unix domain sockets when you log out.  If I could
consistently reproduce the issue, I could probably diagnose it.

<rant>
I'll be frank.  GDM and GNOME are acting like playground bullies here,
and my strong inclination is to kick them off the playground rather than
try to placate them.  I'm sick of open source developers acting as if
local Linux sessions are the only thing that matters.  It probably has a
lot to do with the pervasive myth that Linux desktops matter, when the
reality is that Linux has a 3-4% market share among desktop operating
systems.  An honest reckoning with that would lead one to conclude that
Linux should lean into on-demand remote virtual desktop solutions rather
than making those solutions more difficult.  TurboVNC and VirtualGL are
in their 20th year, they are deployed in most supercomputer centers, and
numerous large organizations (both public and private) use them for
on-demand remote access to large-scale computing and graphics
resources.  Is it too much to ask that we not be treated like red-headed
stepchildren?  I'm sick of spending my life hacking around other
people's lack of forethought, and I'm even sicker of being paid a
pittance for it.
</rant>

> I also attach a server + client log in the error case
> (G3 + gdm + G4 in VNC) in case you have an idea.
>
> Regarding virtualgl: On a box I ran "vglserver_config" before having
> lightdm installed.
> Can I just "unconfigure" and then reconfigure it so that it configures
> lightdm also?

You don't even need to unconfigure it.  You can just configure it
again.  vglserver_config is idempotent, meaning that it won't configure
anything that is already configured.

[DRC]

Felix,

Can you please provide more specific information about how you are

starting the TurboVNC session (and in what order relative to logging in

locally?)  I would still like to reproduce this issue and attempt to fix it.

DRC

[Felix Natter]

hello DRC,

thank you for your intent to fix this bug!
I am _pretty_ sure that this is very easy to reproduce:

- use a plain Ubuntu 22.04 with TurboVNC 3.1 (and dbus-x11)
- login to GNOME3 (with gdm!)
- start TurboVNC:
  - I think I used "vncserver :2" because I didn't know about
    "-listen local"
- the vnc session is created successfully
- connect to hostname:2 from a TVNC 3.1 client: OK
- log out of the physical/:0 GNOME3 session
- the VNC Session (:2) stops working after a while

If these steps do not work for some reason, please tell me,
and I will install a "plain Ubuntu" VM and re-test.

Many Thanks and Best Regards!
Felix

[DRC]

I still can't reproduce it.  Does the issue occur only if the TurboVNC session is started from the local session?  Does it also occur if the TurboVNC session is started independently, e.g. from an SSH session?

I'm suspicious because you said "the physical/:0 GNOME3 session."  On my system, a local GNOME session uses :1 if WaylandEnable=false (which you said was the case on your system.)  That may indicate that something is different about your system.

Also, please upgrade the server to the latest 3.1.x pre-release build (https://turbovnc.org/DeveloperInfo/PreReleases) so that we're on the same page.  That build automatically enables '-listen local', so it shouldn't be necessary to specify Display :2 anymore.

DRC

--

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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/7d68208e-5946-4723-aa68-ad84fc5982d4n%40googlegroups.com.

[Felix Natter]

hi DRC,

I just managed to reproduce it with TVNC 3.1.1-20240118:

- Ubuntu22.04 with GDM3 and GNOME3(x11) session
  - installed ubuntu-mate-desktop, dbus-x11
  - installed some other packages
- "vncserver" (without arguments) took :2 because :1 had a /tmp/.X11-unix/X1
  owned by root

- the vnc session is created successfully

- connect to hostname:2 from a TVNC 3.1.1 client: OK
- log out of the local GNOME3 session
- the VNC Session (:2) disconnects after a short while
- nothing suspicious in (server) log file

> Does it also occur if the TurboVNC session is started independently, e.g. from an SSH session?

No, then I get a different error: the vnc session cannot be unlocked after a lock.

WaylandEnable=false is set.

Many Thanks and Best Regards!
Felix

[DRC]

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 turbovnc-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/600fa4dd-be47-462b-83a8-1bccd5487ecan%40googlegroups.com.

[Felix Natter]

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

[Felix Natter]

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

[DRC]

I will check the diffs when I am in front of my computer, but I performed the same experiment and didn’t see anything in the environment that might explain the problem except for XAUTHORITY. I am also testing with a VM, incidentally, using VMWare Fusion on my Mac, since my physical Linux machines run RHEL derivatives.

On Jan 20, 2024, at 2:59 AM, Felix Natter <felix....@sidact.com> wrote:



--
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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/4b460df9-b5e4-41a1-80bf-62fb4dd0dd98n%40googlegroups.com.

<g3-gdm-vs-ssh-env.diff>

<g3-gdm-vs-lightdm.diff>

<g3-vs-mate-lightdm.diff>

[DRC]

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.

--
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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/4b460df9-b5e4-41a1-80bf-62fb4dd0dd98n%40googlegroups.com.

[Felix Natter]

hello DRC,

the sorted environment logs _within_ TVNC sessions are
attached (PHYSICAL_VNC_DISPLAYMANAGER.envlog):

g3_g3_gdm.envlog: FAILS
g3_mate_gdm.envlog: FAILS
g3_mate_lightdm.envlog: FAILS (not always!)
mate_g3_lightdm.envlog: SUCCEEDS
mate_mate_lightdm.envlog: SUCCEEDS

I hope I got it right this time.

Many Thanks and Best Regards!
Felix

[DRC]

The most relevant comparisons are g3_g3_gdm.envlog vs. mate_g3_lightdm.envlog and g3_mate_gdm.envlog vs. mate_mate_lightdm.envlog, since they compare the same window manager running in TurboVNC with an always-failing vs. an always-successful configuration.

Comparing g3_g3_gdm.envlog vs. mate_g3_lightdm.envlog, nothing really stands out except:

- XAUTHORITY=/run/user/{uid}/gdm/Xauthority in the failing configuration vs. XAUTHORITY=~/.Xauthority in the successful configuration.
- XDG_CONFIG_DIRS and XDG_DATA_DIRS contain /etc/xdg/xdg-ubuntu-xorg in the failing configuration vs. /usr/share/ubuntu in the successful configuration.
- SYSTEMD_EXEC_PID is set in the failing configuration.
- SSH_AGENT_LAUNCHER is set in the failing configuration (but I don't see how that could matter.)
- Some XDG_ display manager variables are set in the successful configuration (but I don't see how that could matter.)

Comparing g3_mate_gdm.envlog vs. mate_mate_lightdm.envlog, nothing really stands out except:

- GNOME_SHELL_SESSION_MODE, GNOME_TERMINAL_SCREEN, and GNOME_TERMINAL_SERVICE are set in the failing configuration (but MATE doesn't use any of those.)
- XAUTHORITY=/run/user/{uid}/gdm/Xauthority in the failing configuration vs. XAUTHORITY=~/.Xauthority in the successful configuration.
- XDG_CONFIG_DIRS and XDG_DATA_DIRS contain /etc/xdg/xdg-ubuntu-xorg in the failing configuration.
- SYSTEMD_EXEC_PID is set in the failing configuration.
- SSH_AGENT_LAUNCHER is set in the failing configuration (but I don't see how that could matter.)

Comparing the sometimes-failing configuration (g3_mate_lightdm.envlog) vs. an equivalent always-successful configuration (mate_mate_lightdm.envlog), nothing really stands out except:

- GNOME_SHELL_SESSION_MODE, GNOME_TERMINAL_SCREEN, and GNOME_TERMINAL_SERVICE are set in the failing configuration (but MATE doesn't use any of those.)
- XDG_CONFIG_DIRS and XDG_DATA_DIRS contain /etc/xdg/xdg-ubuntu-xorg in the failing configuration.
- SYSTEMD_EXEC_PID is set in the failing configuration.
- SSH_AGENT_LAUNCHER is set in the failing configuration (but I don't see how that could matter.)
- Some XDG_ display manager variables are set in the successful configuration (but I don't see how that could matter.)

The next thing I would try is unsetting SYSTEMD_EXEC_PID before invoking /opt/TurboVNC/bin/vncserver.  (Be sure to verify that it remains unset inside of the TurboVNC session.)  If that doesn't change the situation, then try removing /etc/xdg/xdg-ubuntu-xorg from XDG_CONFIG_DIRS and XDG_DATA_DIRS (but I doubt that will matter.)  Unfortunately, I have no other ideas.

DRC

--

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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/06e641ac-f8d8-42fc-b903-686b519f78e9n%40googlegroups.com.

[Felix Natter]

hello DRC,

thanks for the reply. I tried unsetting SYSTEMD_EXEC_PID and also
SYSTEMD_EXEC_PID and XAUTHORITY, but get the same result
(G3_G3_gdm).
Since you have no further ideas (and I have lightdm-mate or locking instead
of logout as workarounds), I think I will give this up.

Many Thanks!!
Felix

[Felix Natter]

Finally, pruning XDG_CONFIG/DATA_DIRS did not help.

Many Thanks for your help.

Felix

[DRC]

Sounds good.  I will revisit if I am ever able to reproduce the issue.

To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/94ab41f9-5cb0-48bb-b9bc-b31e15c7fb8an%40googlegroups.com.

[DRC]

I'm wondering if you could perform an experiment for me.  First configure your system so that it experiences this issue.  Then edit /opt/TurboVNC/bin/xstartup.turbovnc, replace "--exit-with-session" with "--exit-with-x11", and see if the issue still reproduces.  This is just a hunch.

[Felix Natter]

hello DRC,

thank you for the suggestion. Unfortunately the issue is still there :(

Cheers and Best Regards,

Felix