getenv() now always returns NULL in client code about prrte HOT 9 CLOSED

OMPI forwards a plain "VERBOSITY" envar??? Wow - it didn't used to do that and definitely shouldn't without specifically being told to do so. We never forward your environment except for envars prefixed with "PRRTE_" or "PMIX_" - or if you set the "prun" personality to include "ompi", then we also pickup "OMPI_". Anything else has to be directed to be forwarded using the "-x" cmd line option - e.g., -x VERBOSITY or -x VERBOSITY=3.

I have been revamping the PRRTE cmd line to meet OMPI's requirements as we are merging our efforts - i.e., OMPI is going to replace ORTE with PRRTE and the two communities will jointly support PRRTE going forward. So there will be some instability over the next few weeks, particularly in the cmd line parsing. I'm running some tests on it now to see where we stand, but I believe it follows the behavior described above.

from prrte.

from prrte.

I'll check OMPI - we never forward arbitrary envars as it is too easy to break the backend (e.g., forward DISPLAY). I can't believe we actually are doing that, but could be a bug crept into the system and needs to be squashed.

from prrte.

Oh, I bet I know what might be fooling you. If you are running on a single node (where VERBOSITY has been defined in the environment), then yes - that envar will be present for any procs we start on that node. However, I'm certain that we don't forward that envar to a remote node for procs started there.

Are your tests running on a single node? If so, I can check that prun/prrte aren't somehow failing to pickup the local environment. They won't forward it to another node, but they should reflect it in their locally started children.

from prrte.

from prrte.

from prrte.

Okay, here is what I think is going on. When our daemons (including mpirun) start up, they take a snapshot of their local environ. They pass this to each local app proc when it is spawned, along with other variables the daemons define themselves.

We never have mpirun pickup its local environ and forward that to its daemons for delivery to their procs. However, Slurm does do this - so when mpirun/PRRTE use Slurm to start the daemons, the local environ will show up on the node prior to our daemon being started. Thus, the daemons "see" the same local environ that is present at mpirun.

This isn't the case when ssh is used to launch the daemons as ssh doesn't transfer the local environment (at least, not by default). So if you launch via ssh, you won't see the local environ being forwarded. This is my test environment, so I don't see it myself. However, you are using Slurm, and so you do.

I checked and verified this with OMPI master. It is possible that PRRTE's daemons aren't picking up their local environ correctly (given all the recent changes). I'll take a look at that soon.

from prrte.

So how could I tell prun to also forward e.g. all SHMEM_ envvars? Anything to do with —personality?

We could create a "shmem" personality, if you like. Or (once it is working properly) you could forward all SHMEM_* variables by using -x SHMEM_*, though you might have to quote that asterisk on the cmd line. I'll try to look and see if/how that works.

from prrte.

from prrte.