search

TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
761 stars 138 forks source link

`-inetd` not working with systemd.socket #303

Closed rhjdvsgsgks closed 2 years ago

rhjdvsgsgks commented 2 years ago

when i connecting to port 5900, a Xvnc proccess will create and hang, no log output in system log, one cpu core have 100% percent usage, only few kb data transmitting on port 5900. but if i change -inetd to :1 and connect to port 5901 without systemd.socket, everything work well

xvnc@.service

[Unit]
Description=XVNC Per-Connection Daemon

[Service]
ExecStart=-/usr/bin/Xvnc -inetd -query localhost -geometry 1920x1080 -once -SecurityTypes None -localhost
User=nobody
StandardInput=socket
StandardError=journal

xvnc.socket

[Unit]
Description=XVNC Server

[Socket]
ListenStream=5900
Accept=yes

[Install]
WantedBy=sockets.target

ps: same configuration works on tigervnc, but much slower

dcommander commented 2 years ago

X display :0 is normally reserved for the system's "physical" X server, i.e. the X server that is connected to GPU hardware. Normally, Xvnc uses a Unix domain socket corresponding to its X display number in order to communicate with X11 applications on the system, and it uses a corresponding TCP port in order to communicate with VNC viewers. If Xvnc is listening on X display :1, then it will also listen on TCP port 5901, etc. Thus, if there is a physical X server listening on X display :0, then Xvnc will refuse to start unless you specify another X display for it to use. I'm not sure why TigerVNC is working with the configuration above, but it shouldn't be. You should always use Display :1/TCP port 5901 and above for Xvnc sessions unless there is no physical X server on the system.

rhjdvsgsgks commented 2 years ago

X display :0 is normally reserved for the system's "physical" X server, i.e. the X server that is connected to GPU hardware. Normally, Xvnc uses a Unix domain socket corresponding to its X display number in order to communicate with X11 applications on the system, and it uses a corresponding TCP port in order to communicate with VNC viewers. If Xvnc is listening on X display :1, then it will also listen on TCP port 5901, etc. Thus, if there is a physical X server listening on X display :0, then Xvnc will refuse to start unless you specify another X display for it to use. I'm not sure why TigerVNC is working with the configuration above, but it shouldn't be. You should always use Display :1/TCP port 5901 and above for Xvnc sessions unless there is no physical X server on the system.

its a headless device, there is no physical monitor connected and no physical x server running

dcommander commented 2 years ago

Can you give me a complete reproduction procedure? I also need to know which O/S you are using.

rhjdvsgsgks commented 2 years ago

os: archlinuxarm arch: aarch64 systemd ver: 250.3 turbovnc ver: 2.2.7 xserver ver: 21.1.3 xdm ver: 1.1.12 step to reproduce:

  1. install turbovnc and xdm
  2. put xvnc@.service and xvnc.socket to /etc/systemd/system/
  3. start xvnc.socket and xdm.service
  4. use vncviewer connect to ip:5900
  5. viewer printing lot of CConnection: reading protocol version
  6. xvnc cost 100% cpu usage on one core, no output from stderr (and i didn't find any log)

if i use same configuration with tigervnc, xdm login page showed successfully if i execute Xvnc -query localhost -geometry 1920x1080 -once -SecurityTypes None in terminal and use viewer to connect 5900 port. everything works too

dcommander commented 2 years ago

I don't have Arch Linux, so the best I can do is to test it on Fedora. Unfortunately, I could not make it work, even with TigerVNC, and I don't have any more time to spend on it.

dcommander commented 1 year ago

I tried it again with Fedora today, using your exact configuration (but replacing /usr/bin/Xvnc with /opt/TurboVNC/bin/Xvnc), and it worked fine with GDM and XDMCP.