Linux Mint 17.2 MATE 1.10 TurboVNC server stops working after screen saver kicks in about turbovnc HOT 37 CLOSED

I played with it a little bit, it's easy to reproduce, at least on my setup:

• display power management settings don't seem to matter
• lock screen with a password setting doesn't matter
• what matters is the screen saver kicking in: just configure a blank screen saver for 1 min, disconnect the VNC client, let the screen saver kick in (e.g. wait 2 min or so) then reconnect the VNC client. At this point the session is "messed up" in my case.

from turbovnc.

As mentioned in e-mail, I tried to reproduce this with MATE 1.8.x on both CentOS 7 and Ubuntu 14.04 LTS with no luck. Today I also tried to reproduce with MATE 1.10.2 on Ubuntu 15.10, also with no luck. Apparently this is specific to Linux Mint. Don't have time right now to install it.

from turbovnc.

I was going to suggest booting the Live CD in a VM and trying it like that, but I just did and can't reproduce it :( Not sure what's different about my server. Is there a way to enable verbose logging for the server, maybe it offers some clues.

from turbovnc.

Unfortunately not. If I could repro the issue, I could insert some debugging statements into the code and maybe figure out what's up, but if it's intermittent, that makes me wonder whether it might be just luck that prevents you from reproducing it in TigerVNC. You might try different "monolithic" binary releases of TigerVNC (https://bintray.com/tigervnc/stable/tigervnc, tigervnc-Linux-x86_64-{version}.tar.gz are the monolithic versions, i.e. they are self-contained and don't depend on the installed version of X.org), going back to 1.3.x, to see if perhaps one of the earlier binaries exhibits the same problem (that would help nail down whether a specific version of X.org is responsible.) You might also try TurboVNC 1.2.3, which is a completely different X server code base (the 1.2.x series used a weird combination of XFree86 and X.org 7.1. We moved to stock X.org 7.7 in TurboVNC 2.0.)

from turbovnc.

I would not call it intermittent, I can always reproduce it on my server, but not when using the same version Mint 17.2 LiveCD. Of course, my server has been upgraded a few times and there are more packages installed, so it is quite different from the LiveCD.
The other difference is that I boot my server in console mode (it's headless) then ssh in and start the VNC server. With the LiveCD you end up in a MATE session from which I started the VNC server so there are 2 MATE sessions running for the same live user, in parallel. I would not be surprised if that made a difference.

from turbovnc.

GNOME 2 and MATE will look at the DBUS_SESSION_BUS_ADDRESS environment variable and, if it is set, try to re-use the existing instance of D-Bus. That was what the whole unset DBUS_SESSION_BUS_ADDRESS thing in xstartup.turbovnc was about. When you start the TurboVNC Server from within an existing MATE session, unless you have unset DBUS_SESSION_BUS_ADDRESS in your xstartup.turbovnc, it's going to try to re-use the existing D-Bus instance, which is known to fail on certain versions of GNOME 2 and MATE, but maybe that doesn't fail under MATE 1.10.x and just makes it behave differently. unset SESSION_MANAGER is in there for similar reasons.

Long and the short of it-- make sure unset DBUS_SESSION_BUS_ADDRESS and unset SESSION_MANAGER are invoked before invoking mate-session in xstartup.turbovnc.

When I get a chance, I will try to install Linux Mint 17.2 and reproduce the problem that way, but it may be a while before I can do that.

from turbovnc.

Yes, per our email exchanges I did unset both vars in xstratup.turbovnc, I should have mentioned it.
If I find some time I will try and do a VM install of Mint 17.2 too and configure it to start in console mode just like my server.

from turbovnc.

I finally have a working Linux Mint installation. Will try to resolve this in the next week or so.

from turbovnc.

Reproduced!

from turbovnc.

Unfortunately, after 3 hours of digging into this, I am still clueless, and I don't have much more time to devote to it right now. Here's what I know:

• The problem is easy to reproduce by disconnecting the VNC viewer and (from an SSH session) typing:

  DISPLAY=:1 mate-screensaver-command -a
  

• Changing the remote desktop resolution doesn't affect the issue (this was a hunch based on the fact that TigerVNC uses a different default desktop resolution than we do.)

• It isn't an OpenGL thing (running mate-screensaver using VirtualGL doesn't help.)

• In both TigerVNC and TurboVNC, I ran mate-screensaver with debugging output turned on and compared the logs. They are virtually identical, up to the point that TurboVNC locks up, but there is nothing revealing in the log at that point to indicate what might be the cause.

• I compared the set of X extensions between TigerVNC, TurboVNC, and the system-supplied VNC server (vnc4server.) The only extensions that both TigerVNC and vnc4server (the two working solutions) have that TurboVNC doesn't are: DOUBLE-BUFFER and RECORD. I struggle to imagine why either one of those extensions would make a difference with regards to a screen saver.

• I tried the "cross-compatible" build of TigerVNC, which is built against X.org 7.7, just like TurboVNC is. That version of TigerVNC also works, just like the Ubuntu-specific version that uses the system's X server source base.

• I tried disabling DPMS in the TurboVNC Server, since none of the working VNC servers have it. No dice.

The fact that this only occurs when there are no clients connected should probably be a clue, although I really can't imagine what difference that could make. I'm posting this in hopes that someone else who has perhaps seen a similar issue will stumble on it and comment.

from turbovnc.

Aha. Posted too soon, apparently. I think I've found the problem. The issue seems to be related to automatic desktop resizing. When the TurboVNC Viewer connects, it will try to send a desktop resize message to the server, and apparently the server does not like that when the screen saver is active. Since I now know that this is related to X RANDR, I should be able to figure out what TigerVNC is doing differently, since our X RANDR code is based on theirs. I'll keep you posted.

from turbovnc.

As a workaround, you can connect to the server with -desktopsize server to disable automatic desktop resizing, which should prevent the lockup.

from turbovnc.

Please test the latest code in master. I think I fixed this.

from turbovnc.

I tried 2.0.80-20160309 and unfortunately it still does not work. Screen corruption, the screen saver password window is not visible after reconnect, though I can type my password and it unlocks but then I end up with an unresponsive keyboard.

from turbovnc.

This stupid bug unfortunately doesn't reproduce consistently for me. It seems to be somewhat racy, so inserting print statements to attempt to figure out the flow doesn't work. Very frustrating, particularly given the fact that it isn't reproducible on any other platform. I'm trying my best.

from turbovnc.

I thought I had found a more consistent way to reproduce the issue:

DISPLAY=:1 xrandr -s 1600x1200
DISPLAY=:1 mate-screensaver-command -a
DISPLAY=:1 xrandr -s 1280x800

(then connect with the TurboVNC Viewer)

However, it seems like the server still goes through mood swings. Sometimes it wants to fail every single time, and other times, it just won't ever fail no matter what. Makes it really difficult to debug. Apparently the issue is triggered by doing a screen resize while the screen is grabbed by the screen saver. But I swear that 551c855 fixed it for me. I was never able to reproduce the issue with that patch applied. However, I am also unable to reproduce the issue with 05b582e applied, irrespective of the previous commit. This new commit turns off all updates whenever the screen is resizing (TigerVNC does the same thing.) Please try the newest build (build number 20160310):

http://www.turbovnc.org/DeveloperInfo/PreReleases

If that doesn't work, then I give up. A lot of times, issues like this will pop up in more bleeding-edge distributions, but it will take longer for them to manifest in the enterprise distributions that most of my paying customers use. And until or unless the issues work their way down into those enterprise distributions, I usually have no way of getting paid for fixing them. So hopefully this latest patch solves the problem. Otherwise I'm just going to have to leave this open until/unless it affects someone who can financially sponsor the fix. I've already put in something like $700 of unpaid labor on it. Can't afford to donate any more.

from turbovnc.

2.0.80-20160310 is still not working, worse than before, can't even blindly type the password in the screensaver window.
Thanks for trying to fix it and I understand the lack of resources. It's not a big problem, TigerVNC works well for me, I hope it continues to work.

from turbovnc.

That just doesn't even make sense. :( I wonder what could be different between your machine and mine. What GPU and driver version are you running? Wondering if maybe this issue behaves differently under, for instance, an nVidia adapter.

from turbovnc.

The server is headless, it boots in console mode and I start the VNC server form the console directly (I connect to it using Intel AMT also via VNC). The CPU is an Intel Xeon E3-1245 v3 and it has a built-in GPU, otherwise there's no discrete video card.

from turbovnc.

D'oh. Yeah, that was a stupid question on my part. I sometimes think in terms of VirtualGL, in which case the GPU would matter, but it shouldn't make any difference with TurboVNC.

Just so I can try to reproduce your setup as closely as possible, what are you using as a client? What O/S and version of the TurboVNC Viewer?

from turbovnc.

Clients are on OS X 10.11.3, I tried TigerVNC 1.6 and also the 2.0.80-20160309 TurboVNC client with Oracle JDK.

from turbovnc.

OK, OS X is what I'm using as well, so that eliminates one variable at least. :|

from turbovnc.

One last question-- what resolution is your client display? And what resolution is the server before you connect to it (I'm assuming that you're using automatic desktop resizing, so the resolution will change once you connect)? I want to reproduce that aspect of your setup, in case this has something to do with the server overrunning its framebuffer (which would be a serious bug.)

from turbovnc.

If you want to give me a build with debug info to run, please send me an email. Though I'm not sure it's worth the trouble as I'll pretty much be using TigerVNC anyway, but I don't mind helping you debug it if you are willing to sink more time into it.

from turbovnc.

Yes auto resize, xrandr reports 1680x1001 which makes sense given the Mac retina pixel doubling and the window borders/menu. And these are the options I use to start it so it's already at the correct size for clients that may not do resizing:
vncserver :1 -autokill -nolisten tcp -geometry 1680x1001 -depth 24

from turbovnc.

So the client is 1680x1000, but what is the resolution of the server before you connect? Connecting the client presumably causes the server resolution to shrink.

from turbovnc.

As far as a debug build, thanks for the offer, but at this point, I'm trying to solve this mainly because I'm concerned that it might affect other applications. So I want to try as best I can to reproduce what your machine is doing, so I can have some confidence that the problem is fixed before I ask you to test it again.

from turbovnc.

Not sure what you mean. I start the server with -geometry 1680x1001 so I assume that's what it is and that's what xrandr reports once I'm connected. I suppose I can run DISPLAY=:1 xrandr via ssh before the first client connection and also after the client disconnects and see if it changed.

from turbovnc.

For the debug build, I meant you can give me a build with debug enabled and I can send you the log if you want to see what's happening on my machine.

from turbovnc.

OK, so your client resolution is also 1680x1001?

from turbovnc.

I mean the resolution of your Mac's display.

from turbovnc.

"Looks like 1680x1050" scaled to retina resolution (the setting is 1 step up from Default, in the Displays settings)

from turbovnc.

No joy, I'm afraid. I have been able to reproduce the issue exactly twice out of probably 100 tries when the latest patches are applied. I've backed out 05b582e, since you indicated that it made the situation worse for you, and it didn't change the situation for me. Leaving this issue open in case someone else has any bright ideas. I'm officially out of them.

from turbovnc.

This was actually fixed entirely by accident in the process of fixing server-side cursor rendering (6e203d9). Apparently the same sprite function that was messing up the server-side cursor was also creating some sort of deadlock when the MATE screensaver had the screen locked (probably because, somewhere in the bowels on the sprite function, it was also trying to lock the display.) Subsequent commits also overhauled and robustified our X RANDR implementation, which should have doubly fixed the problem (since now the server will never attempt to send a screen update while the screen is in the middle of a resize.) If you can spare a few minutes to test the code in master, I would appreciate it, but this time around, I was able to reliably reproduce the problem, so I'm reasonably confident that it's now fixed.

from turbovnc.

I can give it a try if you can please remind me how I can get a build of master (linux server, os x client as that's my setup). Thanks for continuing to look at this issue.

from turbovnc.

I'll spin a new pre-release build within the next day or so and post the link here once it's uploaded.

from turbovnc.

Sorry for the long delay. There were just too many bugs to fix, and I wanted to take care of all of them before spinning a new build. It is now available here:

http://www.turbovnc.org/DeveloperInfo/PreReleases

from turbovnc.