docker-for-win: use --mmap between portable xpra client for win and xpra server in container

[eine]

Coming from #110 and #117.

x11docker does not support --xpra on Windows ATM. However, successful results running xpra in a docker container have been reported in #117. In #110, a maintainer/developer of xpra, suggested to use option --mmap to improve the performance.

---

@totaam wrote:
In particular, if you care about performance, try to enable mmap. You may have to fiddle with the mmap file path.

@totaam wrote:
I have zero experience trying to get mmap to work from a windows client to a container.
Try to enable -d mmap debug output. See also the mmap=ABSOLUTEFILENAME man page entry.

@totaam wrote:
Here I assume that windows and the container both have access to a filesystem that supports shared memory where you can create the mmap backing file. But that may not be the case... I don't know.

@totaam wrote:
According to the xpra code, the mswindows code path should honour whatever mmap filename you tell it to use. (so I must have tested that at some point)

@mviereck wrote:
xpra server runs in a container in a Linux VM. xpra client runs on Windows.
It is possible to share the same file located on the Windows ntfs file system with x11docker option --sharedir or docker run option --volume.
But I doubt that this allows to share memory. Though, it is worth a try.

@totaam wrote:
You're right. I was thinking of WSL, and shared-memory doesn't even work there yet:
Add support for semaphores and shared memory

---

Let's continue here...

[mviereck]

x11docker does not support --xpra on Windows ATM.

This would only be possible with xpra server on Windows.
x11docker could set it up in WSL. But an x11docker option --xpra on Windows would not provide an obvious advantage compared to currently supported --vcxsrv. For advanced usage of xpra (e.g. HTML5, SSH) a custom setup is (and will be) needed on both Linux and Windows.

mmap file

As being said it is quite likely to fail across VM <-> Windows.
You can test it. Add --sharedir /tmp/mmap --debug to x11docker command. Check the pathes for mmap file in created docker command. Provide them with --mmap=path to xpra server and xpra client accordingly.

[eine]

This would only be possible with xpra server on Windows.

As commented in #121, if some X server exists (even if it is xvfb in a container), xpra server can be built for Windows. I think that it is not done ATM because xpra cannot connect to the windows display server and identify itself as a window manager. Hence, only xpra shadow is available.

x11docker could set it up in WSL. But an x11docker option --xpra on Windows would not provide an obvious advantage compared to currently supported --vcxsrv. For advanced usage of xpra (e.g. HTML5, SSH) a custom setup is (and will be) needed on both Linux and Windows.

I think that the main advantage would be for remote access, since the same xpra server that is running on the host can be accessed either locally or from a remote machine. Plus consistency, as --hostdisplay and --xpra would have a similar scheme in all the platforms. So, the procedure would be:

• Vcxsrv, or xvfb (WSL and Cygwin only), or xvfb in a container.
• xpra server, either on the host or in a container.
• xpra client, either on the host or in a remote.

If Vcxsrv is used, then all the windows are shown on the host. But the other options allow not to execute the client on the host, and no windows are seen.

As being said it is quite likely to fail across VM <-> Windows.
You can test it. Add --sharedir /tmp/mmap --debug to x11docker command. Check the pathes for mmap file in created docker command. Provide them with --mmap=path to xpra server and xpra client accordingly.

I don't understand. --sharedir /tmp/mmap is the same as -v /tmp/mmap:/tmp/mmap, isn't it? Therefore, it will bind a path inside the VM, which I don't know if I can access. Shouln't I try something similar to -v //c/xpra_mmap:/tmp/mmap?

# ./x11docker -i --sharedir /tmp/mmap --debug -- alpine sh
x11docker WARNING: File or folder not found:
  /tmp/mmap

DEBUGNOTE[658.55]: Command at Line 6747 returned with error code 1:
  source /etc/os-release 2> /dev/null
  6885 - ::main::main
DEBUGNOTE[658.65]:
x11docker version: 5.3.4-beta
docker version:    Docker version 18.09.1, build 4c52b90
Host system:
Command:           ./x11docker '-i' '--sharedir' '/tmp/mmap' '--debug' '--' 'alpine' 'sh'
Parsed options:     -i --sharedir '/tmp/mmap' --debug -- 'alpine' 'sh'
DEBUGNOTE[658.82]: Command at Line 5110 returned with error code 1:
  source /etc/os-release 2> /dev/null
  6755 - ::check_host::main::main
x11docker note: Failed to check for sshd. ps -p not supported.

DEBUGNOTE[664.05]: Dependency check for --vcxsrv: 0
DEBUGNOTE[664.52]: Dependency check for --vcxsrv: 0
DEBUGNOTE[664.97]: Dependency check for --vcxsrv: 0
x11docker note: Using X server option --vcxsrv

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

x11docker note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings. Compare issue #108 on github.

DEBUGNOTE[666.23]: Stored background pid 3824 of watchpidlist
DEBUGNOTE[666.38]: Stored background pid 2976 of watchmessagefifo
./x11docker: line 2227: XDG_RUNTIME_DIR: unbound variable
DEBUGNOTE[666.74]: Command at Line 2229 returned with error code 1:
  xwininfo.exe -display :$Newdisplaynumber -root 2>&1
  6795 - ::check_newxenv::main::main
DEBUGNOTE[666.84]: New X environment:
  DISPLAY=10.0.75.1:100 XAUTHORITY=/c/Users/eine/x11docker/cache/alpine-1e6abcba632f858a422fe2c6cda2dcbd/share/Xclientcookie XSOCKET=  X11DOCKER_CACHE=/c/Users/eine/x11docker/cache/alpine-1e6abcba632f858a422fe2c6cda2dcbd
DEBUGNOTE[667.34]: X server command:
  /c/Program\ Files/VcXsrv/vcxsrv.exe :100 \
  -dpms -s off -retro \
  +extension RANDR +extension RENDER +extension GLX \
  +extension XVideo +extension DOUBLE-BUFFER \
  -extension X-Resource +extension SECURITY +extension DAMAGE \
  -extension XINERAMA -xinerama -extension MIT-SHM \
  -auth 'C:/Users/eine/x11docker/cache/alpine-1e6abcba632f858a422fe2c6cda2dcbd/Xservercookie' \
  -listen tcp \
  -extension Composite -extension COMPOSITE \
  -extension XTEST -tst \
  -nowgl -iglx -lesspointer -multiwindow -noclipboard
DEBUGNOTE[667.65]: Users and terminal:
  x11docker was started by:                       eine
  As host user serves (running X, storing cache): eine
  Container user will be:                         eine
  Container user password:                        x11docker
  Getting permission to run docker with:          bash -c
  Running X and other user commands with:         bash -c
  Terminal for password frontend:                 bash -c
  Running on console:                             no
  Running over SSH:                               no
DEBUGNOTE[668.09]: Running on Windows subsystem: MSYS2
  Path to subsystem: C:/msys64/
  Mount path in subsystem: /
x11docker note: Did not find container init system 'tini'.
  This is a bug in your distributions docker package.
  Normally, docker provides init system tini as '/usr/bin/docker-init'.

  x11docker uses tini for clean process handling and fast container shutdown.
  To provide tini yourself, please download tini-static:
    https://github.com/krallin/tini/releases/download/v0.18.0/tini-static
  Store it in one of:
    /home/eine/.local/share/x11docker/
    /usr/local/share/x11docker/

DEBUGNOTE[668.85]: Generated docker command:
  docker.exe run --tty --rm --interactive \
  --name x11docker_X100_1e6abcba632f858a422fe2c6cda2dcbd_alpine \
  --user 197609:197121 \
  --env USER=eine \
  --userns host \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt label=type:container_runtime_t \
  --tmpfs /run --tmpfs /run/lock \
  --volume '/c/Users/eine/x11docker/cache/alpine-1e6abcba632f858a422fe2c6cda2dcbd/share':'/x11docker':rw \
  --workdir '/tmp' \
  --entrypoint env \
  --env 'container=docker' \
  --env 'XAUTHORITY=/x11docker/Xclientcookie' \
  --env 'DISPLAY=10.0.75.1:100' \
  -- alpine /bin/sh - /x11docker/container.CMD.sh
DEBUGNOTE[669.09]: Command at Line 3897 returned with error code 1:
  grep -e '^DOCKER_'
  6835 - ::create_dockerrc::main::main
DEBUGNOTE[670.45]: Stored background pid 8572 of containershell
DEBUGNOTE[670.49]: Waiting for X server --vcxsrv to be ready.
DEBUGNOTE[670.70]: Stored background pid 3008 of Xserver
DEBUGNOTE[670.87]: Set pid 3008 on watchlist: Xserver
DEBUGNOTE[672.37]: Watching pids:
      PID    PPID    PGID     WINPID   TTY         UID    STIME COMMAND
     3008       1   11396      10672  pty0      197609 17:24:30 /c/Program Files/VcXsrv/vcxsrv
DEBUGNOTE[672.42]: --vcxsrv is ready
DEBUGNOTE[672.89]: Running xinitrc
DEBUGNOTE[673.27]: Failed to retrieve trusted cookie from X server. Will bake one myself.
DEBUGNOTE[673.68]: Created cookie: #ffff#fe80000000000000a464f05ba69c7cff#:100  MIT-MAGIC-COOKIE-1  caf0784e9dddf854e9b219315d8cd4f2
#0006#fe80000000000000a464f05ba69c7cff#:100  MIT-MAGIC-COOKIE-1  caf0784e9dddf854e9b219315d8cd4f2
DEBUGNOTE[674.05]: Running dockerrc
DEBUGNOTE[676.23]: Waiting for file creation of /c/Users/eine/x11docker/cache/alpine-1e6abcba632f858a422fe2c6cda2dcbd/xtermready
    DEBUGNOTE[676.55]: Container ID: x11docker_X100_1e6abcba632f858a422fe2c6cda2dcbd_alpine                                     ~ $
                                                                                           DEBUGNOTE[676.91]: Container is up and running.
    DEBUGNOTE[677.27]: Container IP:
                                     DEBUGNOTE[677.70]: Set pid CONTAINERx11docker_X100_1e6abcba632f858a422fe2c6cda2dcbd_alpine on watchlist:
        DEBUGNOTE[677.89]: Host PID of container PID 1: 14034
                                                             DEBUGNOTE[678.25]: Container PID: unknown
                                                                                                      DEBUGNOTE[678.63]: Watching Container: x11docker_X100_1e6abcba632f858a422fe2c6cda2dcbd_alpine
                                                             DEBUGNOTE[678.86]: Process tree of container:
                                                                                                          ./x11docker: line 4983: pstree: command not found
                     DEBUGNOTE[678.87]: Running setup as root in container
                                                                          DEBUGNOTE[679.04]: Process tree of x11docker:
                                                                                                                         ./x11docker: line 6876: pstree: command not found
                                    DEBUGNOTE[679.23]: Container libc: musl
                                                                           DEBUGNOTE[680.01]: Running unprivileged user commands in container
       DEBUGNOTE[681.70]: Running image command: sh
~ $ ls /tmp
XDG_RUNTIME_DIR  group
~ $ ls -la /tmp
total 28
drwxrwxrwt    1 root     root          4096 Feb  2 17:24 .
drwxr-xr-x    1 root     root          4096 Feb  2 17:24 ..
drwxrwxrwt    2 root     root          4096 Feb  2 17:24 .ICE-unix
drwxrwxrwt    2 root     root          4096 Feb  2 17:24 .X11-unix
drwxrwxrwt    2 root     root          4096 Feb  2 17:24 .font-unix
drwx------    2 eine     197121        4096 Feb  2 17:24 XDG_RUNTIME_DIR
-rw-r--r--    1 root     root           402 Feb  2 17:24 group

[mviereck]

I don't understand. --sharedir /tmp/mmap is the same as -v /tmp/mmap:/tmp/mmap, isn't it?

The path is different. On Windows side it is something like /c/msys2/tmp/mmap (I would have to check in VM for exact path). In container it will be /tmp/mmap

Therefore, it will bind a path inside the VM, which I don't know if I can access.

The left path in generated --volume option is the windows path you should provide to xpra windows client.
The right path in generated --volume option is the path within the container you should provide to xpra server in container.

x11docker WARNING: File or folder not found:
/tmp/mmap

My fault; the file does not exist on container startup as xpra has to create it. So no --volume option is added in generated docker command. Try with --sharedir /tmp instead and provide the pathes to xpra with [...]/tmp/mmap.

[mviereck]

Feel free to re-open if this is of interest again.