On 7/17/23 4:27 PM, Grendel G wrote:
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.
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 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
<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 turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/ac0a3762-ce01-41f2-8d98-48a8ddbfa7e7n%40googlegroups.com
<https://groups.google.com/d/msgid/turbovnc-users/ac0a3762-ce01-41f2-8d98-48a8ddbfa7e7n%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 turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/5fcd6b7a-8667-9a5c-819b-b0690bc18250%40virtualgl.org.
