ROOT Version: 6.04 Platform: Linux CentOS 6.4 (final) Compiler: g++
I occasionally run into this X11 error after disconnecting from a session, while I have code running nohup’d in the background. As far as I understand nohup should be disconnecting stdout and stderr, so something like this should not happen. Is this a known problem and potentially has a known solution that would be great.
I suspect it might happen while writing TCanvas() objects, but I have set batch mode to true so it does not interact at all with X11, I would think?
It works sometimes, just not all the time. The bigger the job, the more likely that it crashes from what I have ascertained. I can’t pin down a clear pattern otherwise. I can try screen and see if it works
edit – Screen also throws X11 errors, the same ones.
You should definitely not get X11 errors in batch mode! Could you send us a reproducer? In general, libX11 (and libGX11TTF.so / libGX11.so) must not be loaded. You could check the output of gSystem->GetLibraries() and look for X11.
I can’t actually consistently reproduce this at all. It is buried in a larger multiprocessing pool based steering macro and I have never managed any reproduction, much less a minimal case.
I will try to check gSystem.GetLibraries() at various stages of the program see where X11 is missing! Is it possible that gROOT is changing settings in a wider (or shallower) scope that one might naively expect in a python script?
The contrary - libX11-related libraries should not be loaded in batch mode. PyROOT is expected to obey the batch mode, too, and should not trigger loading of X11 libraries either.