spinalcordtoolbox / sct_docker

Docker distribution of Spinal Cord Toolbox
3 stars 3 forks source link

Variable $MPLBACKEND=agg after running sct_check_dependencies (windows 10) #24

Closed YangHee-Min closed 5 years ago

YangHee-Min commented 5 years ago

Description

After successfully running the container on windows 10, I ran into the following issue while running sct_check_dependencies:

Check if figure can be opened.......................
Second attempt to plot ...

Overwriting environment variable $MPLBACKEND=agg
[FAIL]
(<type 'exceptions.RuntimeError'>, RuntimeError(u'Invalid DISPLAY variable',), <traceback object at 0x7fb27b79c560>)

Steps to Reproduce

  1. Context (system versions): neuropoly/sct:sct-v4.0.0-beta.0-ubuntu-18.04

  2. run container.

  3. Enter command sct_check_dependencies

Expected behavior: Passes all checks with no visible failures.

Actual behavior: Gets following message log: https://pastebin.com/7U9MSePt

zougloub commented 5 years ago

Caused by upstream issue https://github.com/neuropoly/spinalcordtoolbox/issues/2010 aka https://github.com/neuropoly/spinalcordtoolbox/issues/2005

jcohenadad commented 5 years ago

@zougloub figures (and fsleyes) can be opened when i tested sct-docker on windows 10 pro (with docker desktop). This issue seems specific to docker toolbox.

Therefore, are the issues you are referring to here really the problem in this issue, or is it related to how docker toolbox (and/or Xming) is configured?

zougloub commented 5 years ago

sct_check_dependencies shouldn't have to to interact with X, it should create off-screen figures. I suspect that there are remains of non-OO Matplotlib API somewhere. The problem wouldn't happen if a specific off-screen Canvas was created on a Figure.

Now if proper X11 forwarding is implemented, the problem is worked around.

@YangHee-Min was the command entered in the container terminal, or in an SSH terminal?

YangHee-Min commented 5 years ago

@zougloub I believe It was container terminal

zougloub commented 5 years ago

Then there was no X forwarding, this doesn't have much to do with docker but has to do with the fact that we're running SCT on a headless environment (upstream issue).

jcohenadad commented 5 years ago

ok, but in any case we want X forwarding because we need FSLeyes, right?

zougloub commented 5 years ago

Strictly speaking sct_check_dependencies and most SCT commands should work even without forwarding, and it's only when we want to launch fsleyes that we should have to run another terminal on top of the one of dockers.

But the sct_docker documentation mainly mentions use of an SSH terminal.

lrouhier commented 5 years ago

practical solution that works right now :

Otherwise it is possible to connect by SSH to the docker system (through git bash for example). The .xlaunch file does not return anything. Do we need to have lxterminal on the win10 pc to make it work ?

lrouhier commented 5 years ago

After a clean install, it worked on another laptop but the docker shared folder was not able to transfer files from windows to the docker system working on it unless someone had a fix for #13 After the test I made with MobaXterm it started working on mine as well. I used sudo apt-update. as suggested in #12.

zougloub commented 5 years ago

The sct-win_docker_toolbox.xlaunch (if you're using Docker Toolbox it's the one to use) tries to launch ssh -p 2222 -Y sct@192.168.99.100 using git's SSH client. Take a look ath the file contents (it's XML) and see if you can troubleshoot it?

lrouhier commented 5 years ago

I tried that but in the end, running the sudo apt-update command worked. I don't know why it did not work the first time around...

jcohenadad commented 5 years ago

ok so i guess we can now close this issue, and put our efforts in solving #13