[Solved - partly] VNC-Server doesn't serve X-Windows

After installing TigerVNC with

pacman -S tigervnc

and setting up x0vncserver as described here

enabling and starting the server with systemctl, I have been connecting to it with Remmina on a Linux Mint machine via an SSH-Tunnel. Connects fine, however my client does only show me the wallpaper or the kodi-gui, but seems not to recieve the panel (polybar), X-windows or the popup-menu.

Btw, hi there and thanks for providing the awesome arch distribution and this forum. I’m new here and a linux-beginner.

The configuration looks like this:

~/.vnc/config
securitytypes=tlsvnc
desktop=sandbox
geometry=1280x720
dpi=96
localhost
alwaysshared

I assume the cause is a flawed xstartup-script, which looks like this:

~/.vnc/xstartup
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
exec /etc/X11/xinit/xinitrc

Should there be an openbox reference?

Try by unlogin & relogin, might do the trick on the Polybar. Did it on my side when I add apps.

You need to edit in Openbox in order to add anything in there. Use the Openbox Menu Editor for that.

Edit: Added stuff.

Some readings do help also, here s a link: http://openbox.org/wiki/Help:Contents

Hi, altman, thanks for your post, but are we talking about the same topic here?

My problem as described is basically a misconfuguration of the vncserver. I don’t believe the Openbox Menu Editor contributes in any way to solve that.

Tought that you didn t see your apps installed in the Polybar as well as on Openbox.

Well , you wrote about Openbox references,Quoted from your post:

Should there be an openbox reference?

I put a link for that, as for your issue(s) maybe someone can chim in.

How did you saved your sysctl settings & how you did it, might help in here as well.

Edit: & as for the other part of the post I didn t answer as I thought someone else might help you better on this topic(vpn issues), sorry that I tried to help, no worries .

How did you saved your sysctl settings & how you did it, might help in here as well.

systemctl enable x0vncserver
systemctl start x0vncserver
systemctl status x0vncserver

and voila the service is up and running, survives a reboot of the machine as well. However, as described here the server is invoced by the shell command ’ /usr/bin/x0vncserver -display :0 -rfbport 5900 -passwordfile /home/foo/.vnc/passwd &’ and there is a reference to the passwordfile but not to the config file or the xstartup-script.

edit: so, yes, you might have helped me looking into the right direction…

someone else might help you better on this topic(vpn issues)

Maybe, although there is no vpn issue involved so far.

or maybe I should look there: https://www.hep.phy.cam.ac.uk/vnc_docs/faq.html
or there: https://www.hep.phy.cam.ac.uk/vnc_docs/faq.html#q21

in case I found a solution I’m going to paste it here and mark the topic as solved…

According to the wiki the x-startup script that you are using should be considered like a ~/.xinitrc

You can see what is in your xinitrc and pick out just what you want, but given your existing script is using an xinitrc I’ll assume I can too. I would suggest trying something like this for your vnc startup script.

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &

# shouldn't need to exec it, ~/.xinitrc already exec(s) the main process
source ~/.xinitrc

I’m really not sure why the wiki is saying to unset the dbus environment variables, so we’re just gonna run with it and assume they are being re-set by the vnc.

Lemme know if this helps


EDIT: I see you’re using the default /etc/X11/xinit/xinitrc

This script doesn’t really have much going on, see for yourself

cat /etc/X11/xinit/xinitrc

It starts a few programs and runs twm, I don’t have a lot of experience with twm but I don’t believe it has true X support. It’s basically one of the smallest (and in my opinion worst) window managers of all time, so my above solution should work for you :crossed_fingers:

I started x0vncserver from a terminal (local and remote) which lead to the following result:

foo@fileserver ~ % x0vncserver -display :0 -rfbport 5900 -passwordfile /home/foo/.vnc/passwd

Sun Aug 26 19:25:20 2018
Geometry: Desktop geometry is set to 1280x720+0+0
XDesktop: Using evdev codemap

XDesktop: XTest extension present - version 2.2
XDesktop: RANDR extension not present
XDesktop: Will not be able to handle session resize
Main: Listening on port 5900

Sun Aug 26 19:25:38 2018
Connections: accepted: 10.10.10.10::60666
SConnection: Client needs protocol version 3.8
SConnection: Client requests security type VeNCrypt(19)
SVeNCrypt: Client requests security type TLSVnc (258)

Sun Aug 26 19:25:56 2018
XDesktop: Enabling 8 buttons of X pointer device
XDesktop: Allocated shared memory image
VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
VNCSConnST: Client pixel format depth 16 (16bpp) little-endian rgb565
^C
Sun Aug 26 19:28:02 2018
Connections: closed: 10.10.10.10::60666 (Server shutdown)
EncodeManager: Framebuffer updates: 2848
EncodeManager: Tight:
EncodeManager: Solid: 292 rects, 1.54152 Mpixels
EncodeManager: 4.27734 KiB (1:704.692 ratio)
EncodeManager: Bitmap RLE: 29 rects, 104.226 kpixels
EncodeManager: 2.45996 KiB (1:82.89 ratio)
EncodeManager: Indexed RLE: 1.313 krects, 4.94993 Mpixels
EncodeManager: 755.43 KiB (1:12.8181 ratio)
EncodeManager: Full Colour: 1.678 krects, 6.96162 Mpixels
EncodeManager: 2.4652 MiB (1:5.39406 ratio)
EncodeManager: Tight (JPEG):
EncodeManager: Full Colour: 1.259 krects, 55.45 Mpixels
EncodeManager: 18.1457 MiB (1:5.8293 ratio)
EncodeManager: Total: 4.571 krects, 69.0073 Mpixels
EncodeManager: 21.3552 MiB (1:6.16586 ratio)
TLS: TLS session wasn’t terminated gracefully
ComparingUpdateTracker: 315.187 Mpixels in / 76.3494 Mpixels out
ComparingUpdateTracker: (1:4.12822 ratio)
Main: Terminated
x0vncserver -display :0 -rfbport 5900 -passwordfile /home/foo/.vnc/passwd 6,47s user 0,92s system 4% cpu 2:41,55 total

So, it says

Client needs protocol version 3.8

Hmmmm.

Hi natemaia, thanks for your input. Indeed I haven’t cat into the xinitrc so far. And my archlabs-machine doesn’t even have twm installed, so I assume whichever script is invoced, it is supposed to use openbox instead of twm (as mentioned in my first post).

The ~/.xinitrc on my archlabs-machine seems to be the standard archlabs-script and while nano into it I have found

#!/bin/sh

# this file is executed when calling startx

# To run a different WM, set session="WM" below, or run:
#    startx ~/.xinitrc WM

# [..more code..]

# Do NOT put commands below the exec lines
case $session in
    i3|i3wm) exec i3 ;;
    bsp|bspwm) exec bspwm ;;
    xfce|xfce4) exec startxfce4 ;;
    openbox) exec openbox-session ;;
    awesome) exec awesome ;;
    *) exec "$1" # Unknown, try running it
esac

which looks not only good but even very neat to me. There is the same copy of an ~/.xinitrc script in /root/ as well. I am mentioning that, because I assume (!!! don’t know) that in the context of a foobar.service file ~ is located at /root/. So far my archlabs-machine has no /root/.vnc/ and both config and xstartup are only located at /home/foo/.vnc/ until now.

So once again, thanks for your input.

I believe giving an install of twm a try isn’t necessary. Before I set up a different xstartup script as you suggested, I think I have got to get the location of config and xstartup right.

aaaand YES, this did the trick…

In the script ~/.vnc/xstartup I changed the last line /etc/X11/xinit/xinitrc against ~/.xinitrc - as natemaia suggested - and when starting x0vncserver with

x0vncserver -display :0 -rfbport 5900 -passwordfile /home/foo/.vnc/passwd

in a (remote) terminal, it magically worked.

Next stop, how to make it work as a service.

Just for the record:

The source command isn’t part of the POSIX specification and so shouldn’t be used with a /bin/sh shebang (although it will work in ArchLabs because /bin/sh is symlinked to bash); the portable version is:

. ~/.xinitrc

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot

That will continue to work even if /bin/sh is re-linked to (for example) dash, unlike source.

Works as a service as well, but I don’t know why. There is neither a xstartup file nor a .vnc folder in

/root/
/etc/
/etc/systemd/
/etc/systemd/system/

and foo isn’t the only useraccount on this machine, so I wonder how x0vncserver knows that /home/foo/.vnc/xstartup is the correct startup script to use. Additionally, who knows why the x0vncserver is a kind of slow - compared to a Remmina (Mint) <-> x11vnc (Bunsenlabs) vnc-session and despite of an GBit/s-LAN uplink?

@Head_on_a_Stick: why do you put a . in front of the ~/.xinitrc?

Thx at all. I marked the topic as solved.

edit: performance issues are covered under
https://www.hep.phy.cam.ac.uk/vnc_docs/faq.html#q51

oh, well, topic is not solved. windows are not transported any more. don’t know why.

neither when x0vncserver is invoked by the x0vncserver.service script nor when it is invoked by the command line via a ssh-session.

Edit: just for the record, I am not giving up! :wink:

The script containing that line started with #!/bin/sh: this indicates that the script should be parsed by /bin/sh and it also means that the script should be compatible with the Portable Operating System Interface (POSIX), which is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems.

The idea is that a #!/bin/sh script should be able to run in any Unix-like operating system (and even in Windows under CygWin) and so all such scripts must conform to the POSIX man page:

http://pubs.opengroup.org/onlinepubs/9699919799/

Although #!/bin/sh scripts will run under bash, the reverse may not be true: bash scripts can have features and syntax not found in the POSIX specification which will cause #!/bin/sh scripts to fail unless /bin/sh is symlinked to bash.

These features are called “bashisms” and the source command is an example of such a beast, as declared by the checkbashisms tool (available in the AUR):

empty@hegel:~ $ checkbashisms test                                      
possible bashism in test line 9 (should be '.', not 'source'):
source ~/.xinitrc
1|empty@hegel:~ $

^ As you can see, the suggested POSIX-compliant alternative to source is . (“dot”), which does the exact same thing.

This is all rather irrelevant in ArchLabs though because /bin/sh is symlinked to bash but if you changed this to gain a performance advantage[1] then any #!/bin/sh scripts that contained bashisms would subsequently fail.

[1] AUR package here: https://aur.archlinux.org/packages/dashbinsh/

Thanks for the tip, I’ve used . a fair bit before but started using source as I thought the intent was clearer. Definitely good to know for the future though.

@Head_on_a_Stick: thank you for the comprehensive explanation.