accetto / ubuntu-vnc-xfce-g3

Headless Ubuntu/Xfce containers with VNC/noVNC (G3v6).
MIT License
214 stars 62 forks source link

Blank screen #36

Closed ale-sc closed 1 year ago

ale-sc commented 1 year ago

First of, thank you so much for your images, I've been running them on our server!

Lately I've been having an issue with the g3 images. When I connect to it I get a blank screen and I cannot see the desktop environment.

sudo docker run --rm -p 6901:6901 accetto/ubuntu-vnc-xfce-g3

This does not happen when I use an old legacy image.

sudo docker run --rm -p 6901:6901 accetto/ubuntu-vnc-xfce

I would really appreciate it if you can help me with this matter. Thanks in advance,

Ale

accetto commented 1 year ago

Hello @ale-sc,

thank you for your feedback. I didn't have such a behaviour but I'll try to give a few tips that could help you.

I see that you try to use the noVNC protocol, so I assume, that you access the container via a web browser. So this the first thing you can try to change. You can try a different web browser.

The next thing I would recommend, ist to use a different TCP port on the host instead of 6901. Try something like this:

docker run -it --rm -p 25001:6901 accetto/ubuntu-vnc-xfce-firefox-g3

Then point your web browser to http://localhost:25001 and click the Light or Full noVNC client hyperlink. Change the localhost to your server's name if you do not work on that server locally.

I've also noticed that you start your docker as sudo. You can try to configure Docker so that it doesn't require sudo, as it's described on this page - Linux post-installation steps for Docker Engine.

You can also try to acces the container with a VNC Viewer, e.g. TigerVNC Viewer. Creare the container as

docker run -it --rm -p 25000:5901 accetto/ubuntu-vnc-xfce-firefox-g3

and point the VNC Viewer to :25000.

You can also get more information for troubleshooting if you start the container with the --debug option like this:

docker run -it --rm -p 25001:6901 -p 25000:5901 accetto/ubuntu-vnc-xfce-firefox-g3 --debug

One of the reasons for black screens can be also that, the the display :1 is already in use. The image full readme file describes how you can override the VNC related parameters. However, you can override the display number also during container start, like this:

docker run -it --rm -p 25001:6901 -p 25000:5901 -e DISPLAY=:2 accetto/ubuntu-vnc-xfce-firefox-g3 --debug

Hopefully it'll help you to pinpoint the problem. Otherwise I would need more information about your environment, so I could try to reproduce it.

Regards, accetto

ale-sc commented 1 year ago

Dear accetto,

thank you for your taking the time to answer my question!

I've tried your suggestions but it did not work. In all cases when running the image ubuntu-vnc-xfce-firefox-g3 after connecting with novnc or a vnc viewer I get a blank screen. I've changed the display port and the port number.

I want to point out that if I use the image debian-vnc-xfce-firefox-g3 everything works out perfectly. I just wanted to figure out why isn't it working to avoid that this happens in the future also for those images that now are working.

Additional info.

The output of the debug is the same for the two aforementioned machines and this is the output of the vnc.log file for the machine that is showing the blank screen

headless@6b3721b68df7:~$ cat /dockerstartup/vnc.log 
Using desktop session xfce
xauth:  file /home/headless/.Xauthority does not exist

New '6b3721b68df7:2 ()' desktop is 6b3721b68df7:2

Starting desktop session xfce
xinit /etc/X11/Xsession startxfce4 -- /usr/bin/Xvnc :2 -depth 24 -geometry 1360x768 -rfbport 5901 -auth /home/headless/.Xauthority -desktop 6b3721b68df7:2 () -pn -rfbauth /home/headless/.vnc/passwd
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.

Xvnc TigerVNC 1.13.0 - built Feb  3 2023 08:34:05
Copyright (C) 1999-2022 TigerVNC Team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12013000

Fri Mar  3 09:02:30 2023
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on all interface(s), port 5901
 vncext:      created VNC server for screen 0
xinit: XFree86_VT property unexpectedly has 0 items instead of 1

Fri Mar  3 09:04:08 2023
 Connections: accepted: 127.0.0.1::57116
 SConnection: Client needs protocol version 3.8
 SConnection: Client requests security type VeNCrypt(19)
 SVeNCrypt:   Client requests security type VncAuth (2)

Fri Mar  3 09:04:11 2023
 VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian rgb888
 VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian bgr888
 ComparingUpdateTracker: 0 pixels in / 0 pixels out
 ComparingUpdateTracker: (1:-nan ratio)

while this is the output of the xsession-errors

headless@6b3721b68df7:~$ cat .xsession-errors 
Xsession: X session started for  at Fri Mar  3 09:02:30 UTC 2023
localuser:headless being added to access control list
dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument
dbus-update-activation-environment: setting NOVNC_HOME=/usr/libexec/noVNCdim
dbus-update-activation-environment: setting HEADLESS_USER_NAME=headless
dbus-update-activation-environment: setting FEATURES_FIREFOX_PLUS=1
dbus-update-activation-environment: setting FEATURES_SCREENSHOOTING=
dbus-update-activation-environment: setting HOSTNAME=6b3721b68df7
dbus-update-activation-environment: setting SHLVL=0
dbus-update-activation-environment: setting HOME=/home/headless
dbus-update-activation-environment: setting DESKTOP_SESSION=xfce
dbus-update-activation-environment: setting STARTUPDIR=/dockerstartup
dbus-update-activation-environment: setting HEADLESS_USER_ID=1000
dbus-update-activation-environment: setting FEATURES_BUILD_SLIM_TOOLS=1
dbus-update-activation-environment: setting FEATURES_BUILD_SLIM_XSERVER=1
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-eOdHEHcJdk,guid=e6c0c69054e0ea7284fab1876401b7a6
dbus-update-activation-environment: setting FEATURES_FIREFOX=1
dbus-update-activation-environment: setting VNC_COL_DEPTH=24
dbus-update-activation-environment: setting VNC_VIEW_ONLY=false
dbus-update-activation-environment: setting _=/usr/bin/vncserver
dbus-update-activation-environment: setting FEATURES_BUILD_SLIM_XFCE=1
dbus-update-activation-environment: setting PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
dbus-update-activation-environment: setting FEATURES_BUILD_SLIM_FIREFOX=1
dbus-update-activation-environment: setting DISPLAY=:2
dbus-update-activation-environment: setting HEADLESS_USER_GROUP_NAME=headless
dbus-update-activation-environment: setting XDG_CURRENT_DESKTOP=XFCE
dbus-update-activation-environment: setting FEATURES_VNC=1
dbus-update-activation-environment: setting XDG_SESSION_DESKTOP=xfce
dbus-update-activation-environment: setting XAUTHORITY=/home/headless/.Xauthority
dbus-update-activation-environment: setting FEATURES_NOVNC=1
dbus-update-activation-environment: setting NO_AT_BRIDGE=1
dbus-update-activation-environment: setting NOVNC_PORT=6901
dbus-update-activation-environment: setting GDMSESSION=xfce
dbus-update-activation-environment: setting FEATURES_THUMBNAILING=
dbus-update-activation-environment: setting GPG_AGENT_INFO=/home/headless/.gnupg/S.gpg-agent:0:1
dbus-update-activation-environment: setting HEADLESS_USER_GROUP_ID=1000
dbus-update-activation-environment: setting PWD=/home/headless
dbus-update-activation-environment: setting VNC_RESOLUTION=1360x768
dbus-update-activation-environment: setting XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/
dbus-update-activation-environment: setting XDG_CONFIG_DIRS=/etc/xdg/xdg-xfce:/etc/xdg
dbus-update-activation-environment: setting FEATURES_BUILD_SLIM_NOVNC=1
dbus-update-activation-environment: setting FEATURES_VERSION_STICKER=1
dbus-update-activation-environment: setting VNC_PW=headless
dbus-update-activation-environment: setting VNC_PORT=5901
/usr/bin/startxfce4: X server already running on display :2
_IceTransmkdir: ERROR: euid != 0,directory /tmp/.ICE-unix will not be created.
xfce4-session: No SSH authentication agent found

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.280: Failed to spawn gpg-agent: Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.292: Unable to launch "xfwm4": Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.295: Unable to launch "xfsettingsd": Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.298: Unable to launch "xfce4-panel": Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.301: Unable to launch "Thunar": Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.304: Unable to launch "xfdesktop": Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.308: Unable to launch "xdg-user-dirs-update" (specified by autostart/xdg-user-dirs.desktop): Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:56): xfce4-session-WARNING **: 09:02:31.311: Unable to launch "xfsettingsd" (specified by autostart/xfsettingsd.desktop): Failed to close file descriptor for child process (Operation not permitted)
accetto commented 1 year ago

Hello @ale-sc,

it's really interesting, because the images based on Ubuntu and Debian use exactly the same startup scripts. One would expect, that they both either work or not work.

I've tried to reproduce the issue, but I was not able to get the blank screen.

Can you closer describe your environment? Are you on the cloud?

(By the way, I've done some adjustments in the examples of my previous post, so be careful by comparision.)

The logs you've posted look more or less OK with the exception of the last part of the .xsession-errors log.

The last few lines say that the xfce4 session was not correctly started. You can compare it with the working image based on Debian.

You can test it also the following way.

Start the container interactively like this:

docker run -it --rm -p 25000:6901 -p 25001:5901 accetto/ubuntu-vnc-xfce-firefox-g3 bash

You'll enter the container and then you can check the process tree:

headless@dac90a2abd62:~$ pstree

### output should look like this
tini-+-dbus-daemon
     |-dbus-launch
     |-dconf-service---2*[{dconf-service}]
     |-gpg-agent
     |-mousepad---3*[{mousepad}]
     |-startup.sh-+-bash---python3
     |            |-bash---pstree
     |            `-xinit-+-Xvnc
     |                    `-xfce4-session-+-Thunar---2*[{Thunar}]
     |                                    |-xfce4-panel-+-panel-14-action---2*[{panel-14-action}]
     |                                    |             |-panel-6-systray---2*[{panel-6-systray}]
     |                                    |             |-panel-8-pulseau---2*[{panel-8-pulseau}]
     |                                    |             `-2*[{xfce4-panel}]
     |                                    |-xfdesktop---2*[{xfdesktop}]
     |                                    |-xfsettingsd---2*[{xfsettingsd}]
     |                                    |-xfwm4---2*[{xfwm4}]
     |                                    `-2*[{xfce4-session}]
     `-xfconfd---2*[{xfconfd}]

I assume that your output will look differently.

I'm not sure at the moment why your xfce4 session is not starting correctly. Looks like a permission issue.

Have you bound the folder /dockerstartup to an external volume?

Have you extended my image with your Dockerfile?

You can also test the container as the root user like this:

docker run -it --rm -p 25000:6901 -p 25001:5901 --user 0:0 accetto/ubuntu-vnc-xfce-firefox-g3

Does it help?

Regards, accetto

accetto commented 1 year ago

I've just published Release 23.03 with TigerVNC 1.13.1 bugfix release.

Please let me know if it has solved your issue.

ale-sc commented 1 year ago

I've tested it and got the same results, the ubuntu image does not work, while the debian works fine!

Yes the xfce manager does not start on the ubuntu one, here is the output of pstree

headless@0b39ca24d68d:~$ pstree
tini-+-dbus-daemon
     |-dbus-launch
     |-startup.sh-+-bash---python3---python3
     |            |-bash---pstree
     |            `-xinit-+-Xvnc
     |                    `-xfce4-session---3*[{xfce4-session}]
     `-xfconfd---3*[{xfconfd}]

also I am not binding any folder to anything in particular, here is the exact command that I use to start both images

sudo docker run -it --rm -p 20000:6901 -e DISPLAY=:2 accetto/ubuntu-vnc-xfce-firefox-g3 --debug bash

I also tried the --user 0:0 option but no luck, the outcome is always the same, the debian image works while the ubuntu one does not.

thanks for your help!

Ale

accetto commented 1 year ago

Hello @ale-sc,

it's really very strange, but the Xfce4 stuff is not starting for some reason. Unfortunatelly I'm still not able to reproduce the issue.

I've just uploaded a special temporary image accetto/ubuntu-vnc-xfce-g3:debug-issue-36. I've excluded the pre-configuration files and set the user to root (0:0). Otherwise it's the latest image based on Ubuntu 22.04 LTS. Can you try it please?

Btw, have you the same issue with the image based on Ubuntu 20.04 LTS?

Can you also try to start the container without using sudo?

Regards, accetto

ale-sc commented 1 year ago

Hi there,

sorry for replying so late, I've tried the temporary image with no luck unfortunately. I haven't had the chance to test running the container with no sudo, I'll test this soon,

How do you I test the image based on ubuntu 20.04?

thanks,

Ale

accetto commented 1 year ago

Hello @ale-sc ,

those are the images with the 20.04 tags. For example, accetto/ubuntu-vnc-xfce-g3:20.04 is based on Ubuntu 20.04 LTS.

In between I was able to reproduce similar behaviour while working on other issues. However, it happens only if I bind the complete directory /home/headless on Windows.

Are you also on WIndows and do you bind the complete /home/headless directory?

Nevertheless, I'm marking this issue as a bug and I'm already working on a fix.

Regards, accetto

markNZed commented 1 year ago

Hi, I was seeing the same behavior with a black/blank screen in noVNC running accetto/ubuntu-vnc-xfce-firefox-g3:latest on a swarm node (Ubuntu Linux server), I tested it on a Windows WSL2 Docker client and it worked. I then tried accetto/ubuntu-vnc-xfce-firefox-g3:20.04 on the server and it worked, so something weird going on with the 22.04 release it seems.

accetto commented 1 year ago

Hi, I've just updated the temporary image for debugging - accetto/ubuntu-vnc-xfce-g3:debug-issue-36-v2.

Can you test it please and let me know if it has helped?

Please let me also know, if you're on Windows and if you've bound the complete folder home/headless.

ale-sc commented 1 year ago

Hi,

ubuntu 20.04 works fine, unfortunately your last image does not. I run my images from an ubuntu server.

It seems that there are some issues with the x-system here is a portion of the .xsession-errors file

/usr/bin/startxfce4: X server already running on display :2
_IceTransmkdir: ERROR: euid != 0,directory /tmp/.ICE-unix will not be created.
xfce4-session: No SSH authentication agent found

(xfce4-session:61): xfce4-session-WARNING **: 19:49:47.591: Failed to spawn gpg-agent: Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:61): xfce4-session-WARNING **: 19:49:47.606: Unable to launch "xfwm4": Failed to close file descriptor for child process (Operation not permitted)

(xfce4-session:61): xfce4-session-WARNING **: 19:49:47.610: Unable to launch "xfsettingsd": Failed to close file descriptor for child process (Operation not permitted)

Interestingly, part of the x-system works, for example if I start thunar from the terminal I can see it through my browser but the window manager itself is not starting, here is a screenshot of the running thunar

image

Ale

accetto commented 1 year ago

Hello @ale-sc,

it's really strange.

However, it can be seen from your screenshot, that you do not have the permissions (?) for your $HOME directory:

issue-36-shot-1

Actually it should look like this:

issue-36-shot-2

Answering the following questions would help by the troubleshooting:

  1. Are you sure that you haven't bound the whole $HOME directory /headless/home to an external folder?

  2. Do you still start docker as sudo?

Btw, I could reproduce it also on Linux, so it seems to be caused only by binding the complete $HOME directory.

Regards, accetto

accetto commented 1 year ago

FYI: I've moved the image accetto/ubuntu-vnc-xfce-g3:debug-issue-36-v2 to the development repository as accetto/headless-ubuntu-g3:debug-issue-36-v2.

I've also developed a similar image that fixes the behaviour on my environment.

It would be nice if you could test, if it helps - accetto/headless-drawing-g3:debug-issue-37

ale-sc commented 1 year ago

Hi there,

this image has the same behavior as well.

About the permissions of the home folder. I am not binding anything, here is the complete command that I use to start the docker

sudo docker run -it --rm -p 20000:6901 -e DISPLAY=:2 accetto/ubuntu-vnc-xfce-g3:debug-issue-36-v2 --debug bash

Also, I am not sure what is going on, they seem fine from the terminal, I think that the issue is with the icons more than with the permissions.

headless@db38f4a13c8c:~$ ls -lah
total 104K
drwxr-xr-x 1 headless headless 4.0K Mar 23 21:10 .
drwxr-xr-x 1 root     root     4.0K Mar 21 18:41 ..
-rw------- 1 headless headless  334 Mar 23 21:10 .ICEauthority
-rw------- 1 headless headless  106 Mar 23 21:10 .Xauthority
drwxr-xr-x 3 headless headless 4.0K Mar 23 21:10 .cache
drwxr-xr-x 1 headless headless 4.0K Mar 23 21:10 .config
drwx------ 3 headless headless 4.0K Mar 23 21:10 .dbus
drwxr-xr-x 3 headless headless 4.0K Mar 23 21:10 .local
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 .vnc
-rw------- 1 headless headless 4.6K Mar 23 21:10 .xsession-errors
drwxr-xr-x 1 headless headless 4.0K Mar 21 18:41 Desktop
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Documents
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Downloads
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Music
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Pictures
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Public
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Templates
drwxr-xr-x 2 headless headless 4.0K Mar 23 21:10 Videos
-rw-r--r-- 1 headless headless  185 Mar 18  2021 readme.md
drwxr-xr-x 1 headless headless 4.0K Mar 21 18:41 tests
headless@db38f4a13c8c:~$ 

I've also searched for files owned by root inside the home folder and no files have come out.

I will try configure docker without sudo in the next days and see if that solves the issue

Ale

accetto commented 1 year ago

In the answer to the issue #37 I've described, that the reason for the black screen or a partially initialized desktop is the missing package libgl1 in the image accetto/ubuntu-vnc-xfce-g3. However, there was a binding of the whole $HOME folder involved. I was also able to reproduce the behaviour in such cases.

The image accetto/ubuntu-vnc-xfce-opengl-g3 already includes the package libgl1.

However, I'm not able to reproduce your issue.

If you'll closer describe your environment, I could try to install a similar machine. Maybe I'll be able to reproduce it then.

accetto commented 1 year ago

I'm removing the bug label, because I'm not able to reproduce the behaviour in any of my testing environments.

accetto commented 1 year ago

I'm closing this issue because I'm not able to reproduce the behaviour and the communication has staled.

deviantintegral commented 1 year ago

I am running into the same issue. For example:

docker run -d -p 5901:5901 --shm-size=1g --rm accetto/ubuntu-vnc-xfce-g3:latest --tail-vnc

Results in a black screen.

docker run -d -p 5901:5901 --shm-size=1g --rm accetto/debian-vnc-xfce-firefox-g3:latest

Works fine.

I see mentioning a possible DISPLAY conflict. I do have a container running with host privileges, but it's on display 99. Given the above isn't passing in any additional permissions, I'd be really surprised if that was the conflict.