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/47f15b63-e088-1338-182f-1bb67c9bf23b%40virtualgl.org.
