H5py: Importing h5py before mpi4py causes OpenMPI warnings

[1313e]

Version information:

• h5py 2.8.0
• HDF5 1.10.2
• Python 3.6.5 | packaged by conda-forge | (default, Apr 6 2018, 13:39:56)
• [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)]
• sys.platform linux
• sys.maxsize 9223372036854775807
• numpy 1.15.0

My 'problem' is really simple: Whenever I execute a script that imports h5py before mpi4py in MPI (on a cluster running UNIX), I get the following warning:

A process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.

The process that invoked fork was:

  Local host:          [[22007,1],2] (PID 94545)

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.

And, yes, this script can be as simple as:

import h5py
from mpi4py import MPI

and running such a script with mpiexec -n 4 python -m mpi4py test.py.

I do not get this warning whenever I import mpi4py before h5py.
I have seen this warning appear on multiple different clusters that use OpenMPI (it does not appear when using MPICH2, for example).

Now, I know that this warning can be prevented by simply importing mpi4py before h5py (or not using OpenMPI), and I have actually never seen any damage being caused or anything, but I simply wanted to raise this issue in case it is a sign of a problem.

Anybody else has ever seen a similar warning before?

[takluyver]

I'm going to drop the milestone for now, because it's not clear what's going on, and until someone understands the problem properly, we can't really aim to fix it.

There's more discussion continuing on the already merged PR #1117.

[msyriac]

Weird, I get the exact same error as @1313e except for the opposite order of imports! (I have a very similar configuration too)

from mpi4py import MPI                                                                                                                               
import h5py
print("done")


mpirun -np 1 script.py 

--------------------------------------------------------------------------
A process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.

The process that invoked fork was:

  Local host:          [[14455,1],0] (PID 196610)

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.
--------------------------------------------------------------------------
done

compared to

import h5py
from mpi4py import MPI                                                                                                                               
print("done")

mpirun -np 1 script.py 
done

[zs7779]

OpenMPI 2.1.1
mpi4py 3.0.0
hdf5 1.8.18
python 3.5.4

Identical warning but not affected by order of import.

import h5py

or

from mpi4py import MPI
import h5py

produce the same warning

[m-walters]

Same as above

[takluyver]

I can't see this documented at all, but looking at the mpi4py code, it appears there is a way to prevent it from initialising MPI, something like this:

import mpi4py
mpi4py.rc(initialize=False)
from mpi4py import MPI

Maybe setting this would make a difference? But of course, if we tell mpi4py not to do the initialisation then something else needs to in code that actually uses MPI.

[takluyver]

1552 might have affected this - does anyone who's seen this want to try building h5py from master?

[jonaslb]

This is likely due to the line MACHINE = platform.machine() near the top in h5py/h5py/h5t.pyx. A similar issue in tqdm is also due to a call to a function in the platform library, see tqdm/tqdm#691.

[takluyver]

Thanks @jonaslb, I think you're right. It's kind of frustrating: platform.machine() calls platform.uname(), which may run a subprocess, but the 'machine' value doesn't depend on that at all.

I think I've worked out how to get the 'machine' (processor architecture) at compile time - can people test PR #1691?