<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 28 Aug 2020, at 22:32, Satish Balay <<a href="mailto:balay@mcs.anl.gov" class="">balay@mcs.anl.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">This is with --download-mpich - or also with --download-openmpi?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I'm currenly using MPICH 3.3.2. This affects all<br class="">
--download-mpich<br class="">
--download-mpich --download-mpich-device=ch3:nemesis<br class="">
--with-mpi-dir=$CONDA_PREFIX<br class="">
<div class=""></div>
</div>
<div><br class="">
</div>
<div>I will try openmpi as well.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
I wonder if there is some mpich/openmpi settings that avoid this.. [or is this from petsc and not mpi]<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I don't think it's a petsc thing. See e.g.</div>
<div><br class="">
</div>
<div>* <a href="https://github.com/amusecode/amuse/issues/243" class="">https://github.com/amusecode/amuse/issues/243</a></div>
<div>* <a href="https://libensemble.readthedocs.io/en/master/FAQ.html#macos-specific-errors" class="">https://libensemble.readthedocs.io/en/master/FAQ.html#macos-specific-errors</a></div>
<div>* <a href="https://stackoverflow.com/questions/18840007/avoid-accept-incoming-network-connections-dialog-in-mpirun-on-mac-osx" class="">https://stackoverflow.com/questions/18840007/avoid-accept-incoming-network-connections-dialog-in-mpirun-on-mac-osx</a></div>
<div>(BTW here they use openmpi, it seems, and have the same)</div>
* <a href="https://stackoverflow.com/questions/17527700/do-you-want-the-application-to-accept-incoming-network-connection" class="">https://stackoverflow.com/questions/17527700/do-you-want-the-application-to-accept-incoming-network-connection</a></div>
<div>* <a href="https://apple.stackexchange.com/questions/3271/how-to-get-rid-of-firewall-accept-incoming-connections-dialog" class="">https://apple.stackexchange.com/questions/3271/how-to-get-rid-of-firewall-accept-incoming-connections-dialog</a></div>
<div>(I didn't get how that reply could be marked as accepted)</div>
<div>* <a href="https://superuser.com/questions/912656/how-do-i-stop-my-mac-from-asking-to-accept-incoming-network-connections" class="">https://superuser.com/questions/912656/how-do-i-stop-my-mac-from-asking-to-accept-incoming-network-connections</a></div>
<div>* …</div>
<div><br class="">
</div>
<div>Vaclav</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
Satish<br class="">
<br class="">
On Fri, 28 Aug 2020, Hapla Vaclav wrote:<br class="">
<br class="">
<blockquote type="cite" class="">On MacOS, maybe you also have lots of firewall popups appearing/disappearing when running tests like<br class="">
Do you want the application "ex29" to accept incoming network connections?<br class="">
<br class="">
They are annoying, disturbing, slowing down, and virtually making any other work on the computer impossible (and driving me crazy).<br class="">
<br class="">
There is not much information about this issue. Usually the hints involve enabling each application separately in Firewall settings (no support for wildcards), which is virtually impossible to do with all PETSc test executables (and not really working for me).<br class="">
<br class="">
Some guys suggest signing the app using codesign<<a href="https://apple.stackexchange.com/a/150711" class="">https://apple.stackexchange.com/a/150711</a>> which also didn't work for me.<br class="">
<br class="">
But I have finally found a reliable solution. So I'm sharing it, also for my own reference - not sure whether it could be added to PETSc directly in some form.<br class="">
<br class="">
It consists in applying a small makefile patch (below) which uses MacOS firewall CLI (which is not much advertised). This way, make adds the executable to the firewall whitelist right after it's produced by a linker.<br class="">
<br class="">
It uses sudo so it asks for your password for the first time.<br class="">
<br class="">
Please let me know if you have a better solution - except of disabling the firewall ;-) - or other comments/questions.<br class="">
<br class="">
See also<br class="">
* man socketfilterfw<<a href="http://www.manpagez.com/man/8/socketfilterfw/" class="">http://www.manpagez.com/man/8/socketfilterfw/</a>><br class="">
* <a href="https://krypted.com/mac-security/command-line-firewall-management-in-os-x-10-10/" class="">
https://krypted.com/mac-security/command-line-firewall-management-in-os-x-10-10/</a><br class="">
<br class="">
Vaclav<br class="">
<br class="">
<br class="">
<br class="">
diff --git a/gmakefile.test b/gmakefile.test<br class="">
index 95ff59b4ab..c513a0bc0c 100644<br class="">
--- a/gmakefile.test<br class="">
+++ b/gmakefile.test<br class="">
@@ -192,18 +192,37 @@ $(TESTDIR)/snes/tests/ex1: PETSC_TEST_LIB = $(PETSC_SNES_LIB)<br class="">
$(TESTDIR)/ts/tests/ex2: PETSC_TEST_LIB = $(PETSC_TS_LIB)<br class="">
$(TESTDIR)/tao/tutorials/ex1: PETSC_TEST_LIB = $(PETSC_TAO_LIB)<br class="">
<br class="">
+define macos-firewall-register<br class="">
+ @APP=$(call abspath, $(1)); \<br class="">
+ FW=/usr/libexec/ApplicationFirewall/socketfilterfw; \<br class="">
+ if ! $$FW --getappblocked $$APP | grep 'is permitted' > /dev/null; then \<br class="">
+ sudo $$FW --add $$APP && \<br class="">
+ sudo $$FW --unblock $$APP; \<br class="">
+ fi<br class="">
+endef<br class="">
+<br class="">
+# Ensure mpiexec.hydra and test executable is on firewall list<br class="">
+define macos-firewall-fix<br class="">
+ $(call macos-firewall-register, $(shell which mpiexec.hydra))<br class="">
+ $(call macos-firewall-register, $(1))<br class="">
+endef<br class="">
+<br class="">
# Test executables<br class="">
$(testexe.F) $(testexe.F90) : $(TESTDIR)/% : $(TESTDIR)/%.o $$^ $(libpetscall)<br class="">
$(call quiet,FLINKER) -o $@ $^ $(PETSC_TEST_LIB)<br class="">
+ $(call macos-firewall-fix,$@)<br class="">
<br class="">
$(testexe.c) $(testexe.cu) : $(TESTDIR)/% : $(TESTDIR)/%.o $$^ $(libpetscall)<br class="">
$(call quiet,CLINKER) -o $@ $^ $(PETSC_TEST_LIB)<br class="">
+ $(call macos-firewall-fix,$@)<br class="">
<br class="">
$(testexe.kokkos.cxx) : $(TESTDIR)/% : $(TESTDIR)/%.o $$^ $(libpetscall)<br class="">
$(call quiet,PETSC_LINK.kokkos.cxx) -o $@ $^ $(PETSC_TEST_LIB)<br class="">
+ $(call macos-firewall-fix,$@)<br class="">
<br class="">
$(testexe.cxx) : $(TESTDIR)/% : $(TESTDIR)/%.o $$^ $(libpetscall)<br class="">
$(call quiet,CXXLINKER) -o $@ $^ $(PETSC_TEST_LIB)<br class="">
+ $(call macos-firewall-fix,$@)<br class="">
<br class="">
# Fortran source files need petsc*.mod, which isn't explicitly managed in the makefile.<br class="">
$(foreach pkg, $(pkgs), $(call concattestlang,$(pkg),F F90)) : $(libpetscall)<br class="">
<br class="">
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>