Hi,
I have python scripts that are run as jobs in a local cluster. They are not expected to produce any display.
In that specific environment, ROOT issues the following error :
Error in TGClient::TGClient: can’t open display “localhost:11.0”, switching to batch mode…
In case you run from a remote ssh session, reconnect with ssh -Y
This does not prevent the script to be successful. However, it is annoying as the jobs gets flagged as failed by the job manager (non empty standard error).
How can I turn that error off ?
The python scripts basically contains the follwing ROOT technology:
from array import array
from ROOT import gROOT,TFile,TTree
gROOT.SetBatch(True)
f = TFile(filename,"READ")
rtree = f.Get("t_trigger")
nev = rtree.GetEntries()
abs_ship_second = array('d',[-1])
rtree.SetBranchAddress("abs_ship_second",abs_ship_second)
for i in range(0,nev):
rtree.GetEntry(i)
...
Parsing the forum, I tried different solutions.
Add at the beginning of the script :
from ROOT import gROOT
gROOT.SetBatch(True)
That did not make any difference.
print(gROOT.IsBatch()) yields True
I even tried to add sys.argv.append(‘-b’) before gROOT.SetBatch(True). No success.
Brut force: set ROOT verbose level to null.
How is the verbosity managed in pyROOT ?
I tried to set gErrorIgnoreLevel to some very low value without success.
The minimal python script that reproduce the problem is a simple
from ROOT import gROOT,TFile,TTree
No need to do anything specific with ROOT. test.py is submitted to the local slurm queuing system.
How can I tell ROOT to be in batch mode, turn this error message off ? test.py (970 Bytes)
Hi,
Indeed, it works. The error message disappears.
However, I feel uncomfortable with that solution.
The code that imports ROOT is part of a broader ensemble that gets its own flags. By chance, -b is not used. But may in the future. Anyway, I don’t want to interfere with the sys.argv.
Is there really no way to manually set ROOT in batch mode ?
For instance with something like gROOT.SetBatch(True)
Thanks !
That seems the only way for now. But indeed the current parsing of the arguments that PyROOT does is something we need to discuss in the team, and see if we want to keep the same behaviour in the new PyROOT.
Cheers,
Enric