From owner-freebsd-net@freebsd.org Tue Jun 18 00:39:40 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B2C15C8F38 for ; Tue, 18 Jun 2019 00:39:40 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 789468976F for ; Tue, 18 Jun 2019 00:39:39 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id A49A1156E40C; Mon, 17 Jun 2019 17:39:17 -0700 (PDT) To: "Ronald F. Guilmette" cc: freebsd-net Subject: Re: localhost woes -- help requested 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> Comments: In-reply-to "Ronald F. Guilmette" message dated "Mon, 17 Jun 2019 13:15:22 -0700." From: Bakul Shah MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <59492.1560818357.1@bitblocks.com> Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jun 2019 17:39:17 -0700 Message-Id: <20190618003925.A49A1156E40C@mail.bitblocks.com> X-Rspamd-Queue-Id: 789468976F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of bakul@bitblocks.com designates 173.228.5.8 as permitted sender) smtp.mailfrom=bakul@bitblocks.com X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:173.228.5.8/29]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bitblocks.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[mail.bitblocks.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.68)[-0.681,0]; IP_SCORE(-0.15)[asn: 46375(-0.67), country: US(-0.06)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:46375, ipnet:173.228.0.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 00:39:41 -0000 On Mon, 17 Jun 2019 13:15:22 -0700 "Ronald F. Guilmette" wrote: Ronald F. Guilmette writes: > Adam wrote: > > >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette > >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, 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.