Setting environment variables on proof slaves

ROOT
1

Hi,
I already know about the TProof::AddEnvVar(…) method to set environment variables before starting a session. I also know about using the “xpd.putenv” configuration parameter to set environment variables for all PROOF slave sessions.

Is there a way to either have something like TProof::AddEnvVar(…) for the “next” PROOF session or changing the configuration of a proof cluster while the PROOF cluster is running?

These features would be very useful to change e.g. the LD_LIBRARY_PATH or other configuration variables
for the slaves of a PROOF cluster without the need to restart the PROOF cluster.

As far as I understand the TProof::AddEnvVar(…) method, the same program that opens the PROOF session has to call TProof::AddEnvVar(…) to set additional environment variables. Is there a way to “keep the session open” and attaching to this session with changed environment variables?

Is there a way to change the configuration of a PROOF cluster as (PROOF) superuser without restarting the PROOF cluster?

Thanks in advance,
Jörgen.

2

Dear Jörgen,

I am not sure to completely understand what you would like to do.

There are two set of applications:

  1. The daemons (probably what you mean by 'PROOF cluster') which take the environment from the scripts starting them (e.g. those in init.d)

  2. The 'proofserv' instances, which are started by the daemons on master and workers each time TProof::Open is executed. This is what we refer to usually as 'PROOF session'.  The 'proofserv' inherit the environment of the daemons plus the additional settings defined by TProof::AddEnvVar and xpd.putenv

So, each time you run TProof::Open you get the latest settings from TProof::AddEnvVar (as you probably know you can remove variables from the list with TProof::DelEnvVar). Changing environment for an existing ‘PROOF session’ can be done using TProof::Exec, e.g.

proof->Exec("gSystem->Setenv(\"MYENV\", \"the value\")")

Note, however, that for some cases this will not be effective (for example, changes in the LD_LIBRARY_PATH for a running application are usually ignored by the loader; the same for the include path …).

Finally

No, this is not currently possible, because it cannot be done for all directives and it also can introduce thread-safety issues. We tried to make the cluster resilient to daemon restarts (the sessions should reconnect after the daemon is restarted) but this feature is still experimental and needs some more debugging. In the future we may consider again the possibility to change the configuration file on the fly, at least for those directives that allow it.

G. Ganis

3

Thanks for your answer.

The reason for my original question is to understand the scenario in which an (existing) application calls TProof::Open(…) but not TProof::AddEnvVar(…).

Now I try to understand what the possibilities are to control the environment variables seen by the ‘proofserv’ instances.

I already understood the following cases:

  • As you told I can control the environment when I start the daemons (by exporting variables before the daemon start or using xpd.putenv). This controls evnironment variables for all proofserv sessions which are started until the deamons are restarted. Changing xpd.putenv without restarting the daemons (and thus changing the environment for all proofserv sessions that are not yet started) is not possible.
  • One can modify the the program which does TProof::Open(…) to call TProof::AddEnvVar(…) to export the LD_LIBRARY_PATH and all environment variables that might change the behavior of “PROOF-slave-code”.

What I try to understand is whether there is a way to change the environment variables which are seen by the proofserv processes without

  • changing the configuration of the whole cluster and restarting all the daemons
    and
  • modify the program which calls TProof::Open to export all environment variables which possibly influence the run-time behavior of the program.

Cheers, Jörgen.

4

Dear Jörgen,

Ok, I see now. No, this is not currently possible.

I see two possible solutions:

  1. Add a ROOTrc-like variable, e.g. Proof.EnvVar, to define envs to be preloaded in the static list managed by TProof::AddEnvVar
  2. Add and env var PROOF_ENV_VARS with a comma-separated list of names of env variables to be automatically included in the list, if defined; i.e., suppose you want to sent over MYENV1, MYENV2 and MYENV3, then you do something like
$ export MYENV1=myenviron1 ; export MYENV2=myenviron2 ; export MYENV3=myenviron3
$ export PROOF_ENV_VARS="MYENV1,MYENV2,MYENV3"
$ (run the application executing TProof::Open(...))

Would any of these fit your needs?
Gerri

5

Hi,
thanks for your answer. After discussing your proposal, I think an environment variable to preload the list of TProof::AddEnvVar would really help us a lot. We would prefer an environment variable to an ROOTrc variable. With a ROOTrc variable it e.g. seems to be much less convenient to toggle some switches just for test cases.

For the time being, I am playing with TProofMgr::DetachSession to “preset” environment in PROOF sessions as a workaround. However this method has some fundamental limitations. Additionally I’ve got a couple of questions concerning ProofMgr::DetachSession and the way how to control how to attach to existing PROOF sessions. I will open a new topic in this forum with these questions, to avoid the mixing of topics.

Cheers,
Jörgen

6

Dear Jörgen,

I have just committed into the trunk a patch adding support for PROOF_ENVVARS.
See root.cern.ch/drupal/content/cont … of-session .

Are you in the position to try this out?
If not, please tell me which version that you are using and if you are building/can built by yourself. I will see in what other way I can provide the patch.

Gerri

7

Sorry for the late reply.
Finally, I’ve tested the PROOF_ENVVARS variable with the trunk version of ROOT and it works like expected and helps a lot. Is it possible to backport this feature to the 5.26 branch?

The “Controlling the environment of a PROOF session” page is a really useful reference, thanks for this, too.

Cheers,
Jörgen.

8

Thanks for the feedback.

Being a new feature we usually do not do this. How critical is this?

Gerri