Comments (9)
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.
Related Issues (20)
- add-hostfile not working on parallel prun commands HOT 20
- RMAPS round_robin bind_multiple issue HOT 1
- Compile failure with "missing separator" HOT 1
- `prte_stdint.h: error: conflicting types for 'intptr_t'; have 'int'` HOT 22
- pterm conflicts with putty HOT 35
- 3.0.2: autogen.pl script fails HOT 8
- mpirun/prte hang after application completion HOT 46
- pterm name collision HOT 1
- OMPI cmd line processing converts all single-dash options to double-dash HOT 3
- Problems dealing with shared TMPDIRs HOT 18
- mpirun --report-bindings segfault HOT 6
- v3.0.3 release checklist
- prted is missing an option '--allow-run-as-root'
- Enabling debugging options for prrte HOT 2
- PR 1907 broke support for at least one non-ssh PLM component HOT 3
- Option --use-hwthread-cpus incorrectly translated to --bind-to :hwthread
- Binding to partially disabled objects HOT 15
- Can't launch prted HOT 22
- Building for Fault Tolerance HOT 6
- Slurm integration HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from prrte.