Log messages
Grendel G
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:
...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
DRC
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
--
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/11174af0-ae85-4583-8ac6-a94ef57e9039n%40googlegroups.com.
Grendel G
DRC
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?
Not "preferred", necessarily. Some users prefer to just invoke VirtualGL via vglrun only for applications that need GPU acceleration.
Your understanding of how VirtualGL integration works in TurboVNC is correct. However, it is important to note that -vgl/$useVGL isn't the default in TurboVNC and that VirtualGL is not required in order to use TurboVNC. Thus, when you are seeking support for TurboVNC, you should always mention when you are using -vgl/$useVGL.
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.
VirtualGL should have printed an error message when it tried and
failed to connect to the 3D X server. That error message may have
ended up in ~/.xsession-errors or some other system location
outside of the TurboVNC Server log. We have no control over
that. Certain Linux distributions hijack the console output from
the window manager and redirect it elsewhere, and that means that
VirtualGL error messages will be redirected elsewhere as well.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/ac0a3762-ce01-41f2-8d98-48a8ddbfa7e7n%40googlegroups.com.