python-wifi-survey-heatmap
python-wifi-survey-heatmap copied to clipboard
jantman
X Display
Bug Report
When attempting to run the survey from Docker, X Display is not set.
Version
0.2.1 (Docker)
Installation Method
Docker container (latest)
docker run \
--net="host" \
--privileged \
--name survey \
-it \
--rm \
-v $(pwd):/pwd \
-w /pwd \
-e DISPLAY=$DISPLAY \
-v "$HOME/.Xauthority:/root/.Xauthority:ro" \
jantman/python-wifi-survey-heatmap
Actual Output
No protocol specified
Unable to access the X Display, is $DISPLAY set properly?
Expected Output
Test to run.
@DustyArmstrong Could you please let me know what OS you're running, along with what desktop environment and window manager/display server?
This is just a hunch, but since I ran into an issue like this with a completely unrelated piece of software that I was using last week... a number of Linux distros have begun using Wayland as the default display server instead of XOrg. This project is only designed to work with XOrg... mainly because I don't have any machine using Wayland.
A simple-ish way to test this should be, in the same shell where you ran that docker command, run echo $DISPLAY and ls -l $HOME/.Xauthority
On a system with a running, working XOrg server, the output should look something vaguely like:
$ echo $DISPLAY
:0
$ ls -l $HOME/.Xauthority
-rw------- 1 jantman jantman 137 Jan 8 16:13 /home/jantman/.Xauthority
Can you please share what you get as output from those commands?
@DustyArmstrong Any update regarding the above?
Sorry for the delay.
I was running on an Ubuntu VM. I have built your container for ARM64 which I'm going to try.
test@ubuntu:~$ echo $DISPLAY
:0
test@ubuntu:~$ ls -l $HOME/.Xauthority
total 0
UPDATE Hi, I got the same error while running the code in docker environment. Although my display server seems to be XOrg:
~$ echo $XDG_SESSION_TYPE
x11
I am also getting the same result as @DustyArmstrong when running the $DISPLAY variable and .Xauthority listing at Home directory.
as root:
~$ echo $DISPLAY
:0
~$ ls -l $HOME/.Xauthority
total 0
As normal user (which cannot run the container):
$ ls -l $HOME/.Xauthority
lrwxrwxrwx 1 root root 29 Feb 2 10:03 /home/david/.Xauthority -> /run/user/1000/gdm/Xauthority
$ echo $DISPLAY
:0
I tried this in a different Linux (Windowsfx before, Ubuntu 20.04 now) with a different Display server (gdm before, XOrg now) and had the exact same error and same output.
Bug Report
When attempting to run the survey from Docker, X Display is not set.
Version
0.2.1 (Docker)
Installation Method
Docker container (latest)
docker run \ --net="host" \ --privileged \ --name survey \ -it \ --rm \ -v $(pwd):/pwd \ -w /pwd \ -e DISPLAY=$DISPLAY \ -v "$HOME/.Xauthority:/root/.Xauthority:ro" \ jantman/python-wifi-survey-heatmapActual Output
No protocol specified Unable to access the X Display, is $DISPLAY set properly?Expected Output
Test to run.
Hi. I had the same problem and i found this solution:
Running the next command each time you open a new session in your computer (each time you power it on) so any user can connect to the container:
xhost +
Source: Commentary from "Puneetse" Jun 2019 https://community.clearlinux.org/t/execute-graphical-applications-from-docker/698/3
PS. While playing around, I killed XOrg PID and had to use the command again after logging in.
Thanks so much, @DavidIsaacPinos ! Can anyone confirm if that solves the issue for you?
Hi, sorry. Sadly I have nobody to test it for me. If @DustyArmstrong can check if it works for him would be cool.
Hi everybody,
for me (on Ubuntu 20.04.4 LTS), the "xhost +" hint does not help.
Maybe it's because I'm running docker in rootless-mode? (See https://docs.docker.com/engine/security/rootless/). Everything else works fine here.
I also tried using /tmp/X11-unix as the passed ro-volume and running the container with --runtime=runc (as suggested here: https://community.clearlinux.org/t/execute-graphical-applications-from-docker/698/5), but it doesn't help, either.
Thanks for all the work!
For those of you having this issue, could you please share the full output of docker info and also let me know if you're running Docker in rootless mode (or if echo $DOCKER_HOST shows anything)?
I'm not sure, but I have a sneaking suspicion that rootless Docker might not play well with X-based GUI apps. But I'm not really sure, since I've never run rootless docker before. That being said, since this container needs to run with host networking and in privileged mode, I'm not sure the survey part would work with rootless docker even if the the UI did...
As mentioned above, I'm using Docker in rootless mode. In fact, there are a few known limitations, look at https://docs.docker.com/engine/security/rootless/#known-limitations - for example, "host network is namespaced". But I'm not sure, if this could cause the problems described. At least this is not "GUI related", is it?
echo $DOCKER_HOST gives me the expected result: unix:///run/user/1000/docker.sock
Here's my output of docker info:
Client:
Context: default
Debug Mode: false
Server:
Containers: 1
Running: 0
Paused: 0
Stopped: 1
Images: 2
Server Version: 20.10.12
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: false
userxattr: true
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
runc version: v1.0.2-0-g52b36a2d
init version: de40ad0
Security Options:
seccomp
Profile: default
rootless
cgroupns
Kernel Version: 5.13.0-10037-tuxedo
Operating System: Ubuntu 20.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.1GiB
Name: InfBkPro14
ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Docker Root Dir: /home/fooBar/.local/share/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Hope this helps... best regards!
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 9
Running: 2
Paused: 0
Stopped: 7
Images: 152
Server Version: 20.10.18
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
runc version: v1.1.4-0-g5fd4c4d
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.4.0-131-generic
Operating System: Ubuntu 20.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.3GiB
Name: ze-XPS-13-9380
ID: LKGQ:RXSY:PNYQ:BEYX:QJW4:H6SR:BQKE:4NJT:BPD3:BN6S:AFEM:5JTK
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
$ echo $DISPLAY
:0
$ ls -l $HOME/.Xauthority
total 0
If I run docker with sudo it works but failed to load the image.
Hmm... I'm still really not sure what's going on here, sorry. As to not loading the image when run as root, have you tried specifying the absolute path to the image?
I'm on PopOS 21.10 and I can confirm the xhost + command suggested by @DavidIsaacPinos gets things working for me.
Anyone who faces problem the following code below resolved my issue on Ubuntu 20.04
xhost +local:docker
