MacOS 12.3.1 on M1 sysconf(_SC_OPEN_MAX) is returning an error

[jsquyres]

This issue started with this post on the users list: https://www.mail-archive.com/users@lists.open-mpi.org/msg34892.html

I Zoom'ed with Scott, and we dug into this a bit. The root cause of the problem appears to be the do_child() function in the default ODLS module. Specifically:

ompi/orte/mca/odls/default/odls_default_module.c

Line 340 in 8a1f456

long fd, fdmax = sysconf(_SC_OPEN_MAX);

This line is calling sysconf() to determine how many FD's to close in the child process that was just forked (before the exec).

On Scott's system, the value returned from this call is -1, which gets interpreted as long_max (i.e., in the billions). His system appears to hang, but it's not hung -- it's really just that the child is looping billions of times calling close() in this loop:

ompi/orte/mca/odls/default/odls_default_module.c

Lines 404 to 411 in 8a1f456

	for(fd=3; fd<fdmax; fd++) {
	if (
	#if OPAL_PMIX_V1
	fd != cd->opts.p_internal[1] &&
	#endif
	fd != write_fd) {
	close(fd);
	}

Scott is running:

We interactively added an opal_output() in the ODLS default component and saw:

• The value returned by sysconf() is -1, which is interpreted as long_max (something in the billions).
• After the call, errno was set to 22/Invalid argument (although I neglected to set errno to 0 before the call to sysconf(), so I'm not 100% sure that that errno value is from that call to sysconf())
• The value of _SC_OPEN_MAX is 5 (which is the same as it is on my Intel MacOS 12.3.1 machine)

This is happening on Open MPI 4.1.x, but since this code hasn't changed in forever, I suspect it's happening on all versions of Open MPI / PRTE.

[jsquyres]

@bosilca found that others are seeing this, too: https://developer.apple.com/forums/thread/666765

Curiously, this is not happening on @bosilca's M1. ☹️

[bosilca]

Apparently you can alter it on OSX with ulimit -n XXX and break things. So, here is a quick patch to protect against such cases:

diff --git a/orte/mca/odls/default/odls_default_module.c b/orte/mca/odls/default/odls_default_module.c
index f8012bb3c9..a05bf70048 100644
--- a/orte/mca/odls/default/odls_default_module.c
+++ b/orte/mca/odls/default/odls_default_module.c
@@ -337,7 +337,7 @@ static int do_child(orte_odls_spawn_caddy_t *cd, int write_fd)
 {
     int i;
     sigset_t sigs;
-    long fd, fdmax = sysconf(_SC_OPEN_MAX);
+    long fd, fdmax;
     char dir[MAXPATHLEN];
 
 #if HAVE_SETPGID
@@ -346,6 +346,11 @@ static int do_child(orte_odls_spawn_caddy_t *cd, int write_fd)
     setpgid(0, 0);
 #endif
 
+    /* be resilient as sysconf is allowed to return -1 for various reasons */
+    if (-1 == (fdmax = sysconf(_SC_OPEN_MAX))) {
+        fdmax = 256;  /* a reasonable number */
+    }
+
     /* Setup the pipe to be close-on-exec */
     opal_fd_set_cloexec(write_fd);
 

[jsquyres]

@bosilca also found this: gradle/gradle#17274

[jsquyres]

@bosilca I expanded on your patch (I made the value be an MCA param, just because of my knee-jerk reaction against hard-coding constants in code) in #10360. Once we agree on the particulars of that PR, I'll cherry-pick it to v4.0.x and PRTE.

[bosilca]

It turns out that OSX has /dev/fd listing the open fd per process (more or less as /proc/self/fd in Linux). So, at least for OSX there is a proper solution (I'll make a PR over the weekend).

It could be worth having that extra security around sysconf, but I think I would rather just not close any file if sysconf fails (because MAX_INT is also a legitimate max number of files, and I don't think we want to waste time trying to close them all).

[jsquyres]

@bosilca We're gearing up for another v4.1.x RC (and probable release), so I merged #10360. I.e., we wanted a fix for v4.1.x, even if it's not the most optimal. If are still working on a better /proc/self/fd-based solution, awesome -- would still love to see it for a future release.