On Fri, Sep 18, 2020 at 10:23 AM Barry Smith <bsm...@petsc.dev> wrote:
> > This email thread doesn't seem to have clear communication. Can we start > at the beginning again please? Please answer my questions directly in the > appropriate lines below in your email response so we know what answer goes > with what question. I know you have done some of these things but it is > unclear what order you did them and the order is important. > > Background: In order to decide if the test in MPI.py works, or needs to > be modified or removed we need clear information about your system BEFORE > you made changes to get things to work. > > 1) Did you add the > > 127.0.0.1 MarksMac-5.local > > to the /etc/hosts yesterday because Satish suggested it, or have you > had it there for a long time? (You should not need it) > Satish suggested MarksMac-302.local. As I said earlier I have seen messages that say something like a network problem, renaming hostname to MarksMac-X.local, where X is +1 the current X. Initially it was MarksMac.local and it made MarksMac-1.local > 2) Please run > > ping -c 2 `hostname` > 09:08 master *= ~/Codes/petsc$ ping -c 2 `hostname` PING marksmac-302.local (127.0.0.1): 56 data bytes Request timeout for icmp_seq 0 --- marksmac-302.local ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss 10:55 2 master *= ~/Codes/petsc$ > > 3) Please remove the line 127.0.0.1 MarksMac-5.local in /etc/hosts > and follow the directions in > > > https://stackoverflow.com/questions/37951379/etc-hosts-ignored-in-mac-el-capitan-10-11-5 > > to flush the DNS cache (note for different versions of MacOS the > command is different). > My takeway here was you need one space between the IP and name. I had a tab here: 127.0.0.1 localhost fixed, but did not help. Its not clear to me what you want me to do. He did two scary (sudo goop) things. One was: sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist Do you want me to do that? > > 4) Please run > > ping -c 2 `hostname` > > 5) Please run a MPI program (doesn't matter which and I don't care how > you installed MPICH or OpenMPI) with > > mpiexec -n 2 ./programname > > does it run, hang or ? > > > Based on this information we can decide what needs to be done next. > > Thanks > > Barry > > As a side note on my Mac > > $ hostname > Barrys-MacBook-Pro-3.local > ~/Src/petsc* (barry/2020-07-07/docs-no-makefiles *>)* > arch-docs-no-makefiles > $ /sbin/ping -c 2 `hostname` > PING barrys-macbook-pro-3.local (127.0.0.1): 56 data bytes > 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.077 ms > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.112 ms > > --- barrys-macbook-pro-3.local ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.077/0.095/0.112/0.018 ms > ~/Src/petsc* (barry/2020-07-07/docs-no-makefiles *>)* > arch-docs-no-makefiles > $ > > We are trying to understand if/why your machine is behaving differently. > > My theory is that if ping -c 2 `hostname` fails then MPICH and OpenMP > mpiexec -n 2 will fail. We need to determine if this theory is correct or > if you have a counter-example. > > > On Sep 18, 2020, at 8:09 AM, Mark Adams <mfad...@lbl.gov> wrote: > > > > On Fri, Sep 18, 2020 at 7:51 AM Matthew Knepley <knep...@gmail.com> wrote: > >> On Fri, Sep 18, 2020 at 7:46 AM Mark Adams <mfad...@lbl.gov> wrote: >> >>> Oh you did not change my hostname: >>> >>> 07:37 master *= ~/Codes/petsc$ hostname >>> MarksMac-302.local >>> 07:41 master *= ~/Codes/petsc$ ping -c 2 MarksMac-302.local >>> PING marksmac-302.local (127.0.0.1): 56 data bytes >>> Request timeout for icmp_seq 0 >>> >>> --- marksmac-302.local ping statistics --- >>> 2 packets transmitted, 0 packets received, 100.0% packet loss >>> 07:42 2 master *= ~/Codes/petsc$ >>> >> >> This does not make sense to me. You have >> >> 127.0.0.1 MarksMac-302.local >> >> in /etc/hosts, >> > > 09:07 ~/.ssh$ cat /etc/hosts > ## > # Host Database > # > # localhost is used to configure the loopback interface > # when the system is booting. Do not change this entry. > ## > 127.0.0.1 localhost > 255.255.255.255 broadcasthost > 127.0.0.1 MarksMac-5.local > 127.0.0.1 243.124.240.10.in-addr.arpa.private.cam.ac.uk > 127.0.0.1 MarksMac-302.local > 09:07 ~/.ssh$ > > > > > >> but you cannot resolve that name? >> >> Matt >> >> >>> BTW, I used to get messages about some network issue and 'changing host >>> name to MarksMac-[x+1].local'. That is, the original hostname >>> was MarksMac.local, then I got a message about changing >>> to MarksMac-1.local, etc. I have not seen these messages for months but >>> apparently this process has continued unabated. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Sep 17, 2020 at 11:10 PM Satish Balay via petsc-users < >>> petsc-users@mcs.anl.gov> wrote: >>> >>>> On Thu, 17 Sep 2020, Matthew Knepley wrote: >>>> >>>> > On Thu, Sep 17, 2020 at 8:33 PM Barry Smith <bsm...@petsc.dev> wrote: >>>> > >>>> > > > On Sep 17, 2020, at 4:59 PM, Satish Balay via petsc-users < >>>> > > petsc-users@mcs.anl.gov> wrote: >>>> > > > >>>> > > > Here is a fix: >>>> > > > >>>> > > > echo 127.0.0.1 `hostname` | sudo tee -a /etc/hosts >>>> > > >>>> > > Satish, >>>> > > >>>> > > I don't think you want to be doing this on a Mac (on anything?) >>>> On a >>>> > > Mac based on the network configuration etc as it boots up and as >>>> networks >>>> > > are accessible or not (wi-fi) it determines what hostname should >>>> be, one >>>> > > should never being hardwiring it to some value. >>>> > > >>>> > >>>> > Satish is just naming the loopback interface. I did this on all my >>>> former >>>> > Macs. >>>> >>>> >>>> Yes - this doesn't change the hostname. Its just adding an entry for >>>> gethostbyname - for current hostname. >>>> >>>> >>> >>>> 127.0.0.1 MarksMac-302.local >>>> <<< >>>> >>>> Sure - its best to not do this when one has a proper IP name [like >>>> foo.mcs.anl.gov] - but its useful when one has a hostname like >>>> "MarksMac-302.local" -that is not DNS resolvable >>>> >>>> Even if the machine is moved to a different network with a different >>>> name - the current entry won't cause problems [but will need another entry >>>> for the new host name - if this new name is also not DNS resolvable] >>>> >>>> Its likely this file is a generated file on macos - so might get >>>> reset on reboot - or some network change? [if this is the case - the change >>>> won't be permanent] >>>> >>>> >>>> Satish >>>> >>> >> >> -- >> What most experimenters take for granted before they begin their >> experiments is infinitely more interesting than any results to which their >> experiments lead. >> -- Norbert Wiener >> >> https://www.cse.buffalo.edu/~knepley/ >> <http://www.cse.buffalo.edu/~knepley/> >> > >
