Now I'm in a quandry - if I show you that its actually Open MPI that is
propagating the environment then you are likely to "fix it" and then tm
users will lose a nice feature. :-)
Can I suggest that "least surprise" would require that MPI tasks get
exactly the same environment/limits/... as mpirun so that "mpirun a.out"
behaves just like "a.out". [Following this principle we modified
tm_spawn to propagate the callers rlimits to the spawned tasks.]
A comment in orterun.c (see below) below suggests that Open MPI is trying
to distinguish between "local" and "remote" processes. I would have
thought that distinction should be invisible to users as much as possible
- a user asking for 4 cpus would like to see the same behaviour if all
4 are local or "2 local, 2 remote".
As to why tm does "The Right Thing": in the case of rsh/ssh the full
mpirun environment is given to the rsh/ssh process locally while in the tm
case it is an argument to tm_spawn and so gets given to the process (in
this case orted) being launched remotely. Relevant lines from 1.3.3 below.
PBS just passes along the environment it is told to. We dont use torque
but as of 2.3.3, it was still the same as OpenPBS in this respect.
Michael just pointed out the slight flaw. The environment should be
somewhat selectively propagated (exclude HOSTNAME etc). I guess if you
were to "fix" plm_tm_module I would put the propagation behaviour in
tm_spawn and try to handle these exceptional cases.
510 /* save the environment for launch purposes. This MUST be
511 * done so that we can pass it to any local procs we
512 * spawn - otherwise, those local procs won't see any
513 * non-MCA envars were set in the enviro prior to calling
514 * orterun
516 orte_launch_environ = opal_argv_copy(environ);
681 /* actually ssh the child */
682 static void ssh_child(int argc, char **argv,
683 orte_vpid_t vpid, int proc_vpid_index)
694 /* setup environment */
695 env = opal_argv_copy(orte_launch_environ);
766 execve(exec_path, exec_argv, env);
128 static int plm_tm_launch_job(orte_job_t *jdata)
228 /* setup environment */
229 env = opal_argv_copy(orte_launch_environ);
311 rc = tm_spawn(argc, argv, env, node->launch_id, tm_task_ids + launched, tm_events + launched);
Ralph Castain wrote:
> Not exactly. It completely depends on how Torque was setup - OMPI isn't forwarding the environment. Torque is.
> We made a design decision at the very beginning of the OMPI project not to forward non-OMPI envars unless directed to do so by the user. I'm afraid I disagree with Michael's claim that other MPIs do forward them - yes, MPICH does, but not all others do.
> The world is bigger than MPICH and OMPI :-)
> Since there is inconsistency in this regard between MPIs, we chose not to forward. Reason was simple: there is no way to know what is safe to forward vs what is not (e.g., what to do with DISPLAY), nor what the underlying environment is trying to forward vs what it isn't. It is very easy to get cross-wise and cause totally unexpected behavior, as users have complained about for years.
> First, if you are using a managed environment like Torque, we recommend that you work with your sys admin to decide how to configure it. This is the best way to resolve a problem.
> Second, if you are not using a managed environment and/or decide not to have that environment do the forwarding, you can tell OMPI to forward the envars you need by specifying them via the -x cmd line option. We already have a request to expand this capability, and I will be doing so as time permits. One option I'll be adding is the reverse of -x - i.e., "forward all envars -except- the specified one(s)".