Dear all, I am working on the integration of various external applications into SNAP, thanks to the Standalone Tool Adapter. These applications are coded in C, C++, Python and Matlab and I am working on Linux.
I have managed to do all the integrations on one computer, installing the bundles works and then running my tools also works.
However, I tried to integrate these applications on another computer but some of the integrations do not work anymore.
I found this strange because on my first computer it works.
At first I thought it was because on this computer I didn’t have sudo rights but when I unzip my bundle outside of SNAP everything works. So I think that’s not the problem.
After investigation, the problem is actually the “–nox11” argument in the Bundled Binaries. Indeed, when I don’t put this argument, the bundle installation fails and no file has been created in the target folder. But when I put this argument in, it works.
Again, this problem only occurs on one computer and on my first computer, everything works.
Does anyone have any idea what might be causing this problem and how to fix it?
--nox11 argument has no effect on SNAP, since it’s something your external applications know about. It’s not really standardized as far as I know, but perhaps it’s used by some popular software like MATLAB. In any case, you’re in the best position to know what
--nox11 does and how it interacts with SNAP.
But, given the argument name, I assume that:
- you’re running Linux, as X11 is rarely encountered on Windows and Mac OS
- the programs which take that argument interpret it as “don’t try to show any UI”
- by default they can run without the UI, but they fail if an X server is not accessible
- you’re not running SNAP over SSH, which could explain differences from one machine to another
I’m rough on the details, but the way things work is:
- GUI applications look for the
DISPLAY environment variable, which is set to something
:0 if you’re in an Xorg session
- if the variable is set, they try to open a connection to the X server socket, which is located under e.g.
- if the variable is not set, or if the connection fails, they might exit with an error
DISPLAY variable might not be set, or the socket might be inaccessible. You can, for example, start to debug this by checking if:
- you’re running under a GUI: if you’re running GPT over SSH or in a Docker container, yeah, the GUI might not be available
DISPLAY variable is set, e.g.:
cat /proc/$(pidof java)/environ | tr '\0' '\n' | grep DISPLAY (this only works if there’s a single Java process, you can get the PID of SNAP using
ps, a task manager etc.
- the X11 socket is available: try
ls -l /tmp/X11 and see which sockets exist and how their permissions look like
- newer systems use Wayland instead of Xorg – you can usually check on the login page. Wayland no longer uses that socket, but most installations will have Xwayland, which provides an X11 server for compatibility. You can, however, disable Xwayland and get a pure Wayland installation, and then your MATLAB and Java programs will not start (but that’s probably not the case, since SNAP is working for you).
- sometimes the Xwayland socket “goes away” (I’ve seen this more than once on GNOME), but logging out, then in fixes it
- you can run SNAP from a terminal, to see if you get any relevant error or warning messages
- my favourite, but somewhat hard to use, tool is
strace. You can run SNAP under
strace -f, which will attach to your external tool, and show every interaction with the operating system. If an error occurs when trying to connect to the X11 socket, it will show up in the output. You can read more about
strace in the docs, or on A zine about strace and What problems do people solve with strace?.
So yeah, there’s probably little that SNAP developers can do without more details, or access to the affected computer or bundles.
Thank you very much for your reply.
The various tips you have given me will help me in solving the problem. I will try these different solutions.