Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] environment variables and MPI_Comm_spawn
From: tom fogal (tfogal_at_[hidden])
Date: 2013-12-13 10:16:28

Hi Ralph, thanks for your help!

Ralph Castain writes:
> It would have to be done via MPI_Info arguments, and we never had a
> request to do so (and hence, don't define such an argument). It would
> be easy enough to do so (look in the ompi/mca/dpm/orte/dpm_orte.c
> code).

Well, I wanted to just report success, but I've only got the easy
side of it: saving the arguments from the MPI_Info arguments into
the orte_job_t struct. See attached "0003" patch (against trunk).
However, I couldn't figure out how to get the other side: reading out
the environment variables and setting them at fork. Maybe you could
help with (or do :-) that?

Or just guide me as to where again: I threw abort()s in 'spawn'
functions I found under plm/, but my programs didn't abort and so I'm
not sure where they went.

> MPI implementations generally don't forcibly propagate envars because
> it is so hard to know which ones to handle - it is easy to propagate
> a system envar that causes bad things to happen on the remote end.

I understand. Though in this case, I'm /trying/ to make Bad Things
(tm) happen ;-).

> One thing you could do, of course, is add that envar to your default
> shell setup (.bashrc or whatever). This would set the variable by
> default on your remote locations (assuming you are using rsh/ssh
> for your launcher), and then any process you start would get
> it. However, that won't help if this is an envar intended only for
> the comm_spawned process.

Unfortunately what I want to play with at the moment are LD_*
variables, and fiddling with these in my .bashrc will mess up a lot
more than just the simulation I am presently hacking.

> I can add this capability to the OMPI trunk, and port it to the 1.7
> release - but we don't go all the way back to the 1.4 series any
> more.

Yes, having this in a 1.7 release would be great!

BTW, I encountered a couple other small things while grepping through
source/waiting for trunk to build, so there are two other small patches
attached. One gets rid of warnings about unused functions in generated
lexing code. I believe the second fixes resource leaks on error paths.
However, it turned out none of my user-level code hit that function at
all, so I haven't been able to test it. Take from it what you will...


> On Wed, Dec 11, 2013 at 2:10 PM, tom fogal <tfogal_at_[hidden]> wrote:
> > Hi all,
> >
> > I'm developing on Open MPI 1.4.5-ubuntu2 on Ubuntu 13.10 (so, Ubuntu's
> > packaged Open MPI) at the moment.
> >
> > I'd like to pass environment variables to processes started via
> > MPI_Comm_spawn. Unfortunately, the MPI 3.0 standard (at least) does
> > not seem to specify a way to do this; thus I have been searching for
> > implementation-specific ways to accomplish my task.
> >
> > I have tried setting the environment variable using the POSIX setenv(3)
> > call, but it seems that Open MPI comm-spawn'd processes do not inherit
> > environment variables. See the attached 2 C99 programs; one prints
> > out the environment it receives, and one sets the MEANING_OF_LIFE
> > environment variable, spawns the previous 'env printing' program, and
> > exits. I run via:
> >
> > $ env -i HOME=/home/tfogal \
> > PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin \
> > mpirun -x TJFVAR=testing -n 5 ./mpienv ./envpar
> >
> > and expect (well, hope) to find the MEANING_OF_LIFE in 'envpar's
> > output. I do see TJFVAR, but the MEANING_OF_LIFE sadly does not
> > propagate. Perhaps I am asking the wrong question...
> >
> > I found another MPI implementation which allowed passing such
> > information via the MPI_Info argument, however I could find no
> > documentation of similar functionality in Open MPI.
> >
> > Is there a way to accomplish what I'm looking for? I could even be
> > convinced to hack source, but a starting pointer would be appreciated.
> >
> > Thanks,
> >
> > -tom