Yes, I am running with the -vgl parameter. I thought this was the preferred way to run if you had VirtualGL and TurboVNC? The way I thought I read the documentation was that by running with -vgl it didn't just run the window manager with VirtualGL but also made it so that anything else you started in that session also ran with VirtualGL. Is this correct?
I did run with "-verbose" on the server and it added more logging. I also ran with "-loglevel 150" on the client. Neither pointed to it being an issue with X on the server side. The log snippets in my original post both had the extended logging turned on. All increased logging was before the <snip> portions. G On Monday, July 17, 2023 at 10:11:55 AM UTC-4 DRC wrote: > That doesn't make sense. The TurboVNC Server is a standalone X server > that has no dependencies on the system's display manager or GPU drivers. > The only reason why such a dependency would exist is if you were trying to > run the window manager using VirtualGL (by passing -vgl to > /opt/TurboVNC/bin/vncserver or setting $useVGL in turbovncserver.conf.) > > To answer your question, however, you can pass -verbose to > /opt/TurboVNC/bin/vncserver or set > > $serverArgs = "-verbose"; > > in turbovncserver.conf to get debugging messages from the TurboVNC > Server's X.org implementation. > > DRC > On 7/17/23 12:46 AM, Grendel G wrote: > > Good evening, > > I had a lot of trouble troubleshooting an issue today because I couldn’t > see from the logs what was actually going wrong. When Xvnc would try to run > when I’d connect to the server from the client on a windows machine using > SSH, the Xvnc process would die and the message the log would output is > simply “Killing Xvnc process ID XXXX” and “establish connection aborted by > the host” on the client side. > > Neither of these were able to lead me to the real issue, which is that > lightDM wasn’t running, and couldn’t run even after reboots because of some > driver issues. > > The request at the heart of this request is – In the logs when Xvnc can’t > run, *would it be possible to print more information on why Xvnc can’t > run in the log?* Instead of just “Killing Xvnc process ID XXXX” ? It took > me a long time to track down what was happening with Xvnc as I thought it > was a network issue. > > > Excessive details below... > > The actual problem I had is: I’m running Debian 12 and a week ago I > updated the kernel. I didn’t know it, but the new kernel wouldn’t just play > nice with my Nvidia drivers. Thing is, they don’t stop playing together > nice until the machine is rebooted, which I didn’t do until a week later, > yesterday. > > Because I mostly run remote - hence TurboVNC - when I went to access the > machine my clue something was wrong wasn’t “No window manager at all” it > was “VNC can’t connect.” The clues I had at the time were: > > > Server log look like: > ...snip... > 17/07/2023 00:18:53 rfbProcessClientNormalMessage: ignoring unknown > encoding -307 (fffffecd) > 17/07/2023 00:18:53 Enabling LastRect protocol extension for client > 127.0.0.1 > 17/07/2023 00:18:53 Enabling Continuous Updates protocol extension for > client 127.0.0.1 > 17/07/2023 00:18:53 Enabling Fence protocol extension for client 127.0.0.1 > 17/07/2023 00:18:53 Enabling GII protocol extension for client 127.0.0.1 > 17/07/2023 00:18:53 Using tight encoding for client 127.0.0.1 > 17/07/2023 00:18:53 Using Tight compression level 0 for client 127.0.0.1 > 17/07/2023 00:18:53 Using 4 threads for Tight encoding > 17/07/2023 00:18:53 Client supports GII version 1 > 17/07/2023 00:18:53 New screen layout: > 17/07/2023 00:18:53 0x00000040 (output 0x00000040): 1240x900+0+0 > 17/07/2023 00:18:53 Continuous updates enabled > 17/07/2023 00:18:53 Continuous updates enabled > 17/07/2023 00:18:53 Continuous updates enabled > Killing Xvnc process ID 6878 > > Host log looks like: > ...snip... > PlatformPixelBuffer: Native pixel format is depth 24 (32bpp) little-endian > rgb888 > CConn: Using pixel format depth 24 (32bpp) little-endian rgb888 > CConn: Requesting Tight encoding > CConn: Screen 0 work area: 0, 0 3072 x 1688 > CConn: Screen 1 work area: -1920, 969 1920 x 1160 > CConn: Spanned work area: 0, 0 3072 x 1688 > Viewport: Set geometry to 909, 364 1254 x 959 > CMsgReaderV3: Server supports GII version 1 > CConn: Enabling GII > ScreenSet: LAYOUT RECEIVED: > ScreenSet: 64 (0x40): 1240x900+0+0 (flags 0x0) > ScreenSet: LAYOUT SENT: > ScreenSet: 64 (0x40): 1240x900+0+0 (flags 0x0) > CConn: Enabling continuous updates > ScreenSet: LAYOUT RECEIVED: > ScreenSet: 64 (0x40): 1240x900+0+0 (flags 0x0) > Write error: An established connection was aborted by the software in your > host machine > CConn: Error writing pointer event: > CConn: com.turbovnc.rdr.ErrorException: Write error: An established > connection was aborted by the software in your host machine > DesktopWindow: Error getting clipboard data: > DesktopWindow: Write error: An established connection was aborted by the > software in your host machine > CConn: Error writing pointer event: > CConn: com.turbovnc.rdr.ErrorException: Write error: An established > connection was aborted by the software in your host machine > > > What I see above on the server side, comparing to a known good log is a > good log and then “Killing process”. On the client side all I see is “Write > error: Established connection aborted." I assumed it was a network thing > for a while based on the errors. > > In the end, Xvnc can’t run because lightdm isn’t running because nvidia > drivers aren’t loaded. But all I have to go on is “process killed” and > “established connection aborted.” If it’s possible – I wasn’t able to get > to the output of Xvnc – info in the log on why Xvnc was killed would be > awesome. > > Note: To test the situation yourself, stop your display manager with > something like “systemctl stop lightdm" and then just try to connect with a > vncviewer. > > > Thanks for your consideration, > > G > > -- > 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/11174af0-ae85-4583-8ac6-a94ef57e9039n%40googlegroups.com > > <https://groups.google.com/d/msgid/turbovnc-users/11174af0-ae85-4583-8ac6-a94ef57e9039n%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/ac0a3762-ce01-41f2-8d98-48a8ddbfa7e7n%40googlegroups.com.
