Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TWM not found #343

Closed
duongnb09 opened this issue Sep 17, 2022 · 6 comments
Closed

TWM not found #343

duongnb09 opened this issue Sep 17, 2022 · 6 comments

Comments

@duongnb09
Copy link

Hi,

I'm trying to run TurboVNC 3.0.1 server with the command /opt/TurboVNC/bin/vncserver in a headless docker container, but I kept getting the error message xstartup.turbovnc: TWM not found. I give up. and the vncserver doesn't seem working. Any ideas on why this happened?

TurboVNC Server (Xvnc) 64-bit v3.0.1 (build 20220815)
Copyright (C) 1999-2022 The VirtualGL Project and many others (see README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC

17/09/2022 07:50:51 Using security configuration file /etc/turbovncserver-security.conf
17/09/2022 07:50:51 Enabled security type 'tlsvnc'
17/09/2022 07:50:51 Enabled security type 'tlsotp'
17/09/2022 07:50:51 Enabled security type 'tlsplain'
17/09/2022 07:50:51 Enabled security type 'x509vnc'
17/09/2022 07:50:51 Enabled security type 'x509otp'
17/09/2022 07:50:51 Enabled security type 'x509plain'
17/09/2022 07:50:51 Enabled security type 'vnc'
17/09/2022 07:50:51 Enabled security type 'otp'
17/09/2022 07:50:51 Enabled security type 'unixlogin'
17/09/2022 07:50:51 Enabled security type 'plain'
(WW) Failed to open protocol names file /usr/lib64/xorg/protocol.txt
17/09/2022 07:50:51 Desktop name 'TurboVNC: duong-unity-build:1 ()' (duong-unity-build:1)
17/09/2022 07:50:51 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
17/09/2022 07:50:51 Listening for VNC connections on TCP port 5901
17/09/2022 07:50:51   Interface 0.0.0.0
17/09/2022 07:50:51 Framebuffer: BGRX 8/8/8/8
17/09/2022 07:50:51 New desktop size: 1240 x 900
17/09/2022 07:50:51 New screen layout:
17/09/2022 07:50:51   0x00000040 (output 0x00000040): 1240x900+0+0
17/09/2022 07:50:51 Maximum clipboard transfer size: 1048576 bytes
(II) Initializing extension Generic Event Extension
(II) Initializing extension SHAPE
(II) Initializing extension MIT-SHM
(II) Initializing extension XInputExtension
(II) Initializing extension XTEST
(II) Initializing extension BIG-REQUESTS
(II) Initializing extension SYNC
(II) Initializing extension XKEYBOARD
(II) Initializing extension XC-MISC
(II) Initializing extension SECURITY
(II) Initializing extension XFIXES
(II) Initializing extension XFree86-Bigfont
(II) Initializing extension RENDER
(II) Initializing extension RANDR
(II) Initializing extension COMPOSITE
(II) Initializing extension DAMAGE
(II) Initializing extension MIT-SCREEN-SAVER
(II) Initializing extension RECORD
(II) Initializing extension DPMS
(II) Initializing extension Present
(II) Initializing extension X-Resource
(II) Initializing extension XVideo
(II) Initializing extension XVideo-MotionCompensation
(II) Initializing extension GLX
(II) IGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(II) Initializing extension VNC-EXTENSION
17/09/2022 07:50:51 VNC extension running!
(II) XKB: Reusing cached keymap
(II) XKB: Reusing cached keymap
xstartup.turbovnc: No window manager specified or found.  Falling back to TWM.
xstartup.turbovnc: TWM not found.  I give up.
Killing Xvnc process ID 1514

@dcommander
Copy link
Member

TurboVNC needs a window manager. If you're looking for a lightweight one, install Xfce in your container and set $wm = "xfce"; in /etc/turbovncserver.conf.

@duongnb09
Copy link
Author

TurboVNC needs a window manager. If you're looking for a lightweight one, install Xfce in your container and set $wm = "xfce"; in /etc/turbovncserver.conf.

Thanks @dcommander for the instruction! I've installed Xfce and configed $wm to "xfce". The TurboVNC server seems working based on the log, but VirtualGL with EGL still cannot be run due to the missing 2D X server. In other thread
Access the GPU without going through an X server
, you said that we can use TurboVNC Server as 2D X server. How to make TurboVNC as 2D X server here?

Here is the log of TurboVNC
image

Here is the output of VirtualGL
image

@dcommander
Copy link
Member

You are confusing the terms. TurboVNC is always the 2D X server. The EGL back end in VirtualGL eliminates the need for a 3D X server. Using VirtuaGL in a Docker container requires nvidia-docker. See https://github.com/dcommander/virtualgl_docker_examples for examples, but note that those Dockerfiles try to pull the 3.0 evolving build of VGL, which no longer exists. They should be updated to use the latest official 3.0.x release (3.0.1 as of this writing.)

@duongnb09
Copy link
Author

duongnb09 commented Sep 19, 2022

You are confusing the terms. TurboVNC is always the 2D X server. The EGL back end in VirtualGL eliminates the need for a 3D X server. Using VirtuaGL in a Docker container requires nvidia-docker. See https://github.com/dcommander/virtualgl_docker_examples for examples, but note that those Dockerfiles try to pull the 3.0 evolving build of VGL, which no longer exists. They should be updated to use the latest official 3.0.x release (3.0.1 as of this writing.)

@dcommander Ok, so my Docker container already had nvidia-docker. The confusing part here is how to make TurboVNC working with VirtualGL. Based on your instructions, we first need to run /opt/TurboVNC/bin/vncserver to create a 2D X server (i.e. a virtual display), then use VirtualGL to run an OpenGL app (e.g. glxspheres64) with EGL back end. I think the issue here is that I can run TurboVNC with the vncserver command, but VirtualGL doesn't pick up the display which is created by TurboVNC. Most tutorials mentioned using TurboVNC viewer/client (in another machine) to run VirtualGL. I guess using the viewer/client is one way to force VirtualGL to use the virtual display from TurborVNC server, but I just want to run the graphic app in the container itself, so there is no need for the viewer/client to be involved here

@dcommander
Copy link
Member

What do you mean by “VirtualGL doesn’t pick up the display”? VirtualGL uses the X server pointed to by the DISPLAY environment variable as a 2D X server. I also don’t understand your statement about the viewer/client. Are you saying that this is a headless application whereby you don’t ever need to see the graphical output? If so, then you don’t need TurboVNC. You could use Xvfb instead. However, you would still need to get VirtualGL working in order to have GPU acceleration.

@dcommander
Copy link
Member

@duongnb09 Please answer the questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants