localhost woes -- help requested

[Bakul Shah]

On Mon, 17 Jun 2019 13:15:22 -0700 "Ronald F. Guilmette" <rfg at tristatelogic.com> wrote:
Ronald F. Guilmette writes:
> Adam <amvandemore at gmail.com> wrote:
>
> >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette <rfg at tristatelogic.com>
> >wrote:
> >> ... except for the browsers, and also one other thing (nmh outbound
> >> email handling).  Now, both Firefox and Opera crash and burn, right
> >> out of the gate, when started from the command line.  In both cases
> >> thet do so both with entirely cryptic failure messages.
> >>
> >> But here's the kicker... I futzed around with this awhile and found
> >> out that if I just change the default value of the DISPLAY environment
> >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then
> >> start up successfully from the command line.
> >>
> >> So, um, what the bleep did I do wrong?
> >>
> >> Here's the output of the command "getent hosts localhost":
> >>
> >> ::1               localhost
> >> 127.0.0.1         localhost  localhost.tristatelogic.com
> >>
> >>
> >> Any hints for how I can debug this mess would be appreciated.
> >>
> >
> >Do you have local_unbound running?  It's probably caching the result.
> >
> >/etc/rc.d/local_unbound stop
> >
> >Then try your changes to /etc/hosts
>
> I have now rebooted the system multiple times, from a cold start, and
> this has had *no* effect on the output generated by "getent hosts localhost".
>
> That is *still* showing me that there exists a mapping from "localhost"
> to an IPv6 address, even though I commented that out in my /etc/hosts
> file.
>
> I really would like to understand why manual edits to /etc/hosts seem
> to have no effect whatosoever.  And more importantly, I'd really still
> like to know whey X applications cannot seem to connect to the X server
> when and if DISPLAY is set to localhost:0.0 while they have no problem
> doing so when DISPLAY is instead set to :0.0

I ran into this as well. I tried tracing getent() through
networking code in libc but this is quite a mess. And gdb
doesn't work reliably either. No doubt there are some new
switches I haven't explored. And threading.

(gdb) where
#0  0x080b127b in __vdso_clock_gettime (clock_id=12, ts=0xbfbfe100)
    at /usr/src/lib/libc/sys/__vdso_gettimeofday.c:149
#1  0x080a1a2e in __clock_gettime (clock_id=12, ts=0xbfbfe100)
    at /usr/src/lib/libc/sys/clock_gettime.c:46
#2  0x080dd47a in __res_state () at /usr/src/lib/libc/resolv/res_state.c:82
#3  0x08097fdf in _ht_gethostbyname (rval=0xbfbfe698, cb_data=0x0,
    ap=0xbfbfe240 "T??\034") at /usr/src/lib/libc/net/gethostbyht.c:244
#4  0x08096f7f in _nsdispatch (retval=0xbfbfe698, disp_tab=0x80f6b30,
    database=<value optimized out>, method_name=0x80f6b7c "gethostbyname2_r",
    defaults=0x80f6af4) at /usr/src/lib/libc/net/nsdispatch.c:704
#5  0x08095dba in gethostbyname_internal (name=0xbfbfe954 "localhost", af=28,
    hp=0x8107a00, buf=0x8107a14 "", buflen=8504, result=0xbfbfe698,
    h_errnop=0xbfbfe694, statp=0x81128d4)
    at /usr/src/lib/libc/net/gethostnamadr.c:572
#6  0x08096539 in gethostbyname2 (name=0xbfbfe954 "localhost", af=28)
    at /usr/src/lib/libc/net/gethostnamadr.c:519
#7  0x08048b39 in hosts (argc=3, argv=0xbfbfe790) at getent.c:309
#8  0x08048402 in main (argc=3, argv=0xbfbfe790) at getent.c:112

Just manually s/localhost/127.0.0.1/g.