Date: Mon, 17 Jun 2019 17:39:17 -0700 From: Bakul Shah <bakul@bitblocks.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: localhost woes -- help requested Message-ID: <20190618003925.A49A1156E40C@mail.bitblocks.com> In-Reply-To: Your message of "Mon, 17 Jun 2019 13:15:22 -0700." <4468.1560802522@segfault.tristatelogic.com> References: <4468.1560802522@segfault.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Jun 2019 13:15:22 -0700 "Ronald F. Guilmette" <rfg@tristatelogi=
c.com> wrote:
Ronald F. Guilmette writes:
> Adam <amvandemore@gmail.com> wrote:
>
> >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette <rfg@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 environmen=
t
> >> 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 localh=
ost".
>
> 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=3D12, ts=3D0xbfbfe100)
at /usr/src/lib/libc/sys/__vdso_gettimeofday.c:149
#1 0x080a1a2e in __clock_gettime (clock_id=3D12, ts=3D0xbfbfe100)
at /usr/src/lib/libc/sys/clock_gettime.c:46
#2 0x080dd47a in __res_state () at /usr/src/lib/libc/resolv/res_state.c:8=
2
#3 0x08097fdf in _ht_gethostbyname (rval=3D0xbfbfe698, cb_data=3D0x0,
ap=3D0xbfbfe240 "T??\034") at /usr/src/lib/libc/net/gethostbyht.c:244
#4 0x08096f7f in _nsdispatch (retval=3D0xbfbfe698, disp_tab=3D0x80f6b30,
database=3D<value optimized out>, method_name=3D0x80f6b7c "gethostbyna=
me2_r",
defaults=3D0x80f6af4) at /usr/src/lib/libc/net/nsdispatch.c:704
#5 0x08095dba in gethostbyname_internal (name=3D0xbfbfe954 "localhost", a=
f=3D28,
hp=3D0x8107a00, buf=3D0x8107a14 "", buflen=3D8504, result=3D0xbfbfe698=
,
h_errnop=3D0xbfbfe694, statp=3D0x81128d4)
at /usr/src/lib/libc/net/gethostnamadr.c:572
#6 0x08096539 in gethostbyname2 (name=3D0xbfbfe954 "localhost", af=3D28)
at /usr/src/lib/libc/net/gethostnamadr.c:519
#7 0x08048b39 in hosts (argc=3D3, argv=3D0xbfbfe790) at getent.c:309
#8 0x08048402 in main (argc=3D3, argv=3D0xbfbfe790) at getent.c:112
Just manually s/localhost/127.0.0.1/g.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190618003925.A49A1156E40C>