An Anatomist window is opened during bv_maker doc
Closed this issue · 16 comments
Describe the bug
An anatomist window is briefly opened during bv_maker doc. I suspect anatomist-gpl because these are the messages I could see when I got to the console after the window appeared:
copying downloadable files... [ 98%] ../../../../../../build/build_files/anatomist-gpl/pyanatomist/autcopying downloadable files... [100%] ../../../../../../build/build_files/anatomist-gpl/pyanatomist/auto_examples/customopenglobject.ipynb
copying static files... done
copying extra files... done
dumping search index in English (code: en)... done
dumping object inventory... done
build succeeded, 23 warnings.
The HTML pages are in ../../../share/doc/pyanatomist-5.1/sphinx.
Sphinx-Gallery successfully executed 0 out of 0 files subselected by:
gallery_conf["filename_pattern"] = '/(anagraphannotate)|(aimsvolumetest)|(anaevensimplerviewer)|(control)|(ellipsoid)|(fusion3D)|(graph)|(graph_building)|(meshtest)|(nomenclatureselection)|(selection)|(volumetest)|(customopenglobject)\\.py'
gallery_conf["ignore_pattern"] = '__init__\\.py'
after excluding 13 files that had previously been run (based on MD5).
embedding documentation hyperlinks...
embedding documentation hyperlinks for auto_examples... [100%] events.html
[ 0%] Built target anatomist-gpl-sphinx
[ 0%] Create "share/doc/5.1"
[ 0%] Built target brainvisa-spm-devdoc
[ 0%] Built target vip-doxygen
Running Sphinx v4.3.2
generating CAPSUL processes docs..._processing
['/usr/bin/python3', '-m', 'capsul.sphinxext.capsul_pipeline_rst', '-i', 'morphologist.capsul', '-o', '/casa/host/src/morphologist/morphologist-gpl/5.1/sphinx/dev_doc/process_docs/morphologist', '--schema']
/casa/host/src/capsul/5.1/capsul/sphinxext/capsul_pipeline_view.py::2023-01-23 11:45:48,081::INFO::Found '14' pipeline(s) in 'morphologist.capsul'.
Environment:
- Engine: Singularity
- Version of BrainVISA: 5.1
- Version of the casa-dev image:
casa-dev-5.1-14
I have already seen this but it doesn't appear every time, or not in every configuration. The pyanatomist doc config (for spninx) begins with instantiating a HeadlessAnatomist instance, which should normally prevent from displaying any GUI window later during docs generation. So either the headless mode does not work in this configuration, or the display is not triggered in this doc, or the documentation process runs a separate process somewhere. Possibly when running notebooks, that's maybe a clue...
When running it manually in my casa-distro, nothing displays, so I don't know how to reproduce it.
I see... On my configuration I can reproduce it every time:
$ make anatomist-gpl-sphinx
Running Sphinx v4.3.2
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
(EE)
Fatal server error:
(EE) Failed to activate virtual core keyboard: 2(EE)
VirtualGL found.
MESA found: /usr/local/lib/mesa/libGL.so.1
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
(EE)
Fatal server error:
(EE) Failed to activate virtual core keyboard: 2(EE)
The current Xvfb does not have a GLX extension. Aborting it.
Headless Anatomist running in normal (non-headless) mode
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-yl243478'
Starting Anatomist.....
config file : /casa/home/.anatomist/config/settings.cfg
PyAnatomist Module present
PythonLauncher::runModules()
global modules: /casa/host/build/build_files/anatomist-gpl/pyanatomist/../../../share/anatomist-5.1/python_plugins
home modules: /casa/home/.anatomist/python_plugins
loading module anacontrolmenu
loading module foldsplit
loading module profilewindow
loading module histogram
loading module bsa_proba
loading module save_resampled
loading module bundles_split_by_cortical_regions
loading module paletteViewer
loading module bundles_small_brains
loading module ana_image_math
loading module palettecontrols
loading module simple_controls
loading module modelGraphs
loading module gradientpalette
loading module selection
loading module meshsplit
loading module volumepalettes
all python modules loaded
Anatomist started.
loading pickled environment... done
loading intersphinx inventory from /casa/host/build/share/doc/soma-base-5.1/sphinx/objects.inv...
[autosummary] generating autosummary for: ana_notebook.ipynb, auto_examples/activateaction.rst, auto_examples/addMenuEntry.rst, auto_examples/aimsvolumetest.rst, auto_examples/anaevensimplerviewer.rst, auto_examples/anagraphannotate.rst, auto_examples/anatomistapiTests.rst, auto_examples/bvProcessSocket.rst, auto_examples/control.rst, auto_examples/customcommands.rst, ..., pyanatomist_examples.rst, pyanatomist_headless.rst, pyanatomist_howto.rst, pyanatomist_notebook.rst, pyanatomist_pyaims_tutorial.rst, pyanatomist_socket.rst, pyanatomist_threaded.rst, pyanatomist_tutorial.rst, pyanatomist_tutorial_nb.ipynb, pyanatomist_wip.rst
generating gallery...
Using Sphinx-Gallery to convert rst text blocks to markdown for .ipynb files.
Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before constructing QGuiApplication.
It seems to be related to the notebook indeed, moreover there is clearly a message indicating failure: Headless Anatomist running in normal (non-headless) mode. Maybe the issue is linked to the hardware OpenGL configuration? My config has an Intel graphics chipset (Intel Corporation UHD Graphics 620). However, one thing that puzzles me is that the behaviour is exactly the same regardless of the opengl=software/opengl=container setting.
Interestingly, unsetting the DISPLAY environment variable or opening the shell with gui=no results in a failure:
$ make anatomist-gpl-sphinx
Running Sphinx v4.3.2
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
(EE)
Fatal server error:
(EE) Failed to activate virtual core keyboard: 2(EE)
VirtualGL found.
MESA found: /usr/local/lib/mesa/libGL.so.1
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-4.xkm" to write keyboard description
> Exiting
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
(EE)
Fatal server error:
(EE) Failed to activate virtual core keyboard: 2(EE)
The current Xvfb does not have a GLX extension. Aborting it.
Configuration error:
There is a programmable error in your configuration file:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinx/config.py", line 329, in eval_config_file
exec(code, namespace)
File "/casa/host/src/anatomist/anatomist-gpl/5.1/pyanatomist/doc/sphinx/conf.py", line 36, in <module>
hana.HeadlessAnatomist()
File "/casa/host/build/python/anatomist/headless.py", line 551, in HeadlessAnatomist
result = setup_headless(allow_virtualgl=allow_virtualgl,
File "/casa/host/build/python/anatomist/headless.py", line 443, in setup_headless
raise RuntimeError('GLX extension missing')
RuntimeError: GLX extension missing
It seems to be linked (again...) to OpenGL, and how it interplays with Xvfb and/or VirtualGL. I will try to look deeper into it, but suggestions are welcome :-)
That's clearly the source of the problem. Now why does Xvfb not work ? It is installed inside the image so should be always the same, and it works both on my desktop workstation (nvidia driver) and on my laptop (intel chipset). I should try through a ssh connection.
Are you using casa-distro locally on your machine, using your account, without any ssh/remote connection ?
I still can't reproduce it.
Yes, I am using casa-distro locally on my laptop, via gnome-terminal. Maybe something specific to my config is that I am running Ubuntu 22.04, and the X server is Xwayland instead of the good old X server.
However, that does not explain failure of Xvfb when I am running bv gui=no:
$ Xvfb :30
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-30.xkm" to write keyboard description
> Exiting
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Cannot open "/var/lib/xkb/server-30.xkm" to write keyboard description
> Exiting
XKB: Failed to compile keymap
Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
(EE)
Fatal server error:
(EE) Failed to activate virtual core keyboard: 2(EE)
This seems to be due to /var/lib/xkb not being writable. If I add container_options='--bind,varlib:/var/lib/xkb:rw' I can launch Xvfb successfully, and make anatomist-gpl-sphinx succeeds.
The weirdest thing is that even if I mount that directory read-only (container_options='--bind,varlib:/var/lib/xkb:ro') I can still launch Xvfb correctly. It only fails when /var/lib/xkb is the one from the container :-/
Strange. Should we mount /var/lib/xkb by default in casa-distro singularity containers (or at least in gui mode) ? Or can it be harmful ?
Just a question: you use --bind,varlib:/var/lib/xkb:rw, not --bind,/var/lib/xkb:/var/lib/xkb ? You mean you are not mounting the host /var/lib/xkb, but a local directory from your host system ?
Exactly, I was mounting an empty directory made especially for that purpose. Nothing to do with /var/lib/xkb on the host. Apparently that directory is used for caching the current keyboard mapping of X servers. It is empty on my host (except for a README.compiled file) and it seems to stay empty also in the container...
OK I see. So should we create an empty dir in the environment HOME and mount it ?
I guess that would fix the issue, yes... it seems a bit ad-hoc but maybe we have no choice :-/
I investigated further by running strace on Xvfb. First it checks if it can write to /var/lib/xkb with access("/var/lib/xkb/", W_OK|X_OK). The strange thing is that this returns success (0) when /var/lib/xkb is the read-only filesystem of the container image, whereas in reality it cannot write.
When /var/lib/xkb is bind-mounted read-only, that call rightfully returns an error -1 EROFS (Read-only file system) and Xvfb fallls back to writing its keymap to /tmp/server-30.xkm and everything works.
When /var/lib/xkb is writeable, the access() call rightfully succeeds and the keymap is written to /var/lib/xkb/server-30.xkm. However, we novor really see it because it is deleted immediately after (unlink("/var/lib/xkb/server-30.xkm")).
Summing up, we could either find a way to make it recognize that /var/lib/xkb is not writeable, or mount it so that it can succeed...
it is deleted immediately after (unlink("/var/lib/xkb/server-30.xkm"))
As far as I know, deleting a file which is already open on Unix is a way to make a temporary, invisible file, which will not have any name conflict with another instance (since the file has no name, it lives using the ref-counting of the filesystem until it is closed). So that makes sense.
OK we'll mount something.
Yes, there is something I don't understand with access, it gives the same weird behaviour in Python:
>>> import os
>>> os.access('/var/lib/xkb', os.X_OK|os.W_OK)
TrueYes, it seems that we are stuck mounting /var/lib/xkb. @denisri just tell me if I should take care of it.
I'll do it, no problem.
Yes, there is something I don't understand with
access, it gives the same weird behaviour in Python:
In my container it returns False. Same on my host system anyway since the directory belongs to root.
I have made the modif and just pushed a new casa-dev-5.3-15 image. Normally you just have to casa_distro pull the new image and the directory creation and mount should be automatic the next time you run the container. Can you test if it fixes the problem please ?
Issue fixed, thanks!