From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#58520: Persistent failure to DNS-lookup hostname Date: Sat, 04 Nov 2023 00:16:52 +0530 Message-ID: <87r0l6fzdv.fsf@gmail.com> References: <875y2j9sm6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8940"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 58520@debbugs.gnu.org, Paul Eggert To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 03 19:47:48 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qyzCt-00026z-V9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Nov 2023 19:47:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyzCb-0007c9-Fs; Fri, 03 Nov 2023 14:47:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyzCZ-0007aD-HH for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 14:47:27 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyzCY-0003JZ-C3 for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 14:47:26 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyzD7-0005ZS-Q7 for bug-gnu-emacs@gnu.org; Fri, 03 Nov 2023 14:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 18:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58520 X-GNU-PR-Package: emacs Original-Received: via spool by 58520-submit@debbugs.gnu.org id=B58520.169903726521390 (code B ref 58520); Fri, 03 Nov 2023 18:48:01 +0000 Original-Received: (at 58520) by debbugs.gnu.org; 3 Nov 2023 18:47:45 +0000 Original-Received: from localhost ([127.0.0.1]:59741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyzCq-0005Yw-SC for submit@debbugs.gnu.org; Fri, 03 Nov 2023 14:47:45 -0400 Original-Received: from mail-pj1-x1043.google.com ([2607:f8b0:4864:20::1043]:49654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyzCo-0005Yh-Su for 58520@debbugs.gnu.org; Fri, 03 Nov 2023 14:47:43 -0400 Original-Received: by mail-pj1-x1043.google.com with SMTP id 98e67ed59e1d1-27ff83feb29so2280518a91.3 for <58520@debbugs.gnu.org>; Fri, 03 Nov 2023 11:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699037221; x=1699642021; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5O6Yc7anbRjcReMInoG9AV5l9R1uOtqgEv9fpFHcoK4=; b=fU6L++sZoFO0EyRBxuuqL/3aaYNYkJNQO1PKaD73sLuRS/xVKUISQ5QxEdqhfn7zWj SgZ297qYOhfOvCoubI+w82ywHel5fmEpnhYtna0inE50dz7NBYGBHgv+BWUZMV1sJO91 2naxKuCRkIysjlwN+M5HvyMW4xbMiwaD81TVQO/OXG5yZ7LZEyKL0Eve/0vJnvxOdb4N GXNBMz0fWJ+gaqOYMctNHIfhfzP6WFb/bMufTBaIMw3FxcT0C0wi9z7+M0t2IHN/Ho7y qB0yXEpLVwiZo7VW4RxAYg51UIdPGsLbgtQr1ZS/D3SoNrmRE01FXWF+gy+p3Xn/v8Be y5GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699037221; x=1699642021; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5O6Yc7anbRjcReMInoG9AV5l9R1uOtqgEv9fpFHcoK4=; b=A5oqgCg7sg8vN4yDei+r2XOkbOipgHUcNOFR3uXxNh7TPWyBlCv5wA9P+S6TRVOmOJ MsnHymOKBaF3XqOyTixj2yNiWwux3ongxEc2kHpLO/IN40FJyApRihNDN/lzTImd9yKd TVPvyuq2KHUDOuUuBcencmHkIOOmtIrVI8NOlmZ7wObGWI43/rCGBrBLxhWqg9Rv6C/w CdL+92JxKivnYACx5X9FOpcbhSUL0TZolmFWVQhI66u+b3MQ4OI5BaQJCsGcnvFnwuWu GZTVfyBqbZzTcLoWXBc8BjXGsGYN8gdjbh383pYAyy2uzH1rfUlFaBZ3CgxSlSWcfYo2 NS7w== X-Gm-Message-State: AOJu0YzZ789Rj4E/+a6nViG0jKrz4VWxFwgCvRYpBT8a6xb6Le2NLS2i Ug44QMaA+ox4v0y6DM0VbkI= X-Google-Smtp-Source: AGHT+IHSvQkPuJ58zic1+jcUmoJJL9ktPpXn7yTT0+FkjvYcyvHiZ+XVgJF8gpvjwx5bhhii1TBVhw== X-Received: by 2002:a17:90a:f2d4:b0:27c:f845:3e3f with SMTP id gt20-20020a17090af2d400b0027cf8453e3fmr22049573pjb.1.1699037220911; Fri, 03 Nov 2023 11:47:00 -0700 (PDT) Original-Received: from localhost ([115.240.90.130]) by smtp.gmail.com with ESMTPSA id 11-20020a170902c14b00b001c75a07f62esm1702112plj.34.2023.11.03.11.46.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 11:47:00 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 03 Nov 2023 12:38:03 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273720 Archived-At: [=E0=AE=B5=E0=AF=86=E0=AE=B3=E0=AF=8D=E0=AE=B3=E0=AE=BF =E0=AE=A8=E0=AE=B5= =E0=AE=AE=E0=AF=8D=E0=AE=AA=E0=AE=B0=E0=AF=8D 03, 2023] Stefan Monnier wrot= e: >> FWIW, I experience this sometimes when I change from an Ethernet >> connection to a WiFi connection (I cannot remember if the inverse is >> true too). This change to another connection once I wake my laptop from >> hibernation. During this change, /etc/resolv.conf definitely changes >> because I use resolvconf to set connection-specific and >> interface-specific DNS nameserver setting. [ I need to set the DNS >> server manually for the Ethernet connection but I can use dhcp for the >> Wifi one. ] > > Sounds like the exact same problem, indeed. > If you ever come up with some further hints about what it needs to > reproduce it (or even better: an actual recipe), I'd be happy to hear the= m. Unfortunately, I only experience this intermittently. This is the first time I see this issue in months (but could also be because I haven't been bringing my laptop as often to the WiFi-only building). > Currently it seems that hibernate/suspend might be related, tho > I suspect it's a red herring. You may be right about that but I cannot exactly prove it because walking while carrying my laptop with its lid open for 2 km is not going to be fun. :-) I don't want to turn off suspend-on-lid-close and potentially overheat my laptop either. >> The other super weird part is that eww _can_ open debbugs.gnu.org just >> fine, but if I use Gnus to fetch the bug report it doesn't... > > Hmm... any chance that you're using some package which makes `eww` use > some external tool instead of `url.el`? No, I don't use any nor do I know of such a package. Actually, an even stranger thing happened with eww that I neglected to mention: some requests to search.brave.com clearly failed with the lookup failure but eww made enough requests to render the webpage from Brave search just fine. This is what I see in the *Messages* buffer 1 Contacting host: www.doi2bib.org:443 2 Error: (error www.doi2bib.org/443 Temporary failure in name resoluti= on) 3 Contacting host: search.brave.com:443 4 search.brave.com/0 Temporary failure in name resolution 5 cdn.search.brave.com/0 Temporary failure in name resolution 6 cdn.search.brave.com/0 Temporary failure in name resolution 7 Contacting host: www.doi2bib.org:443 8 Error: (error www.doi2bib.org/443 Temporary failure in name resoluti= on) 9 Contacting host: www.doi2bib.org:443 10 open-network-stream: www.doi2bib.org/443 Temporary failure in name r= esolution 11 Contacting host: search.brave.com:443 12 cdn.search.brave.com/0 Temporary failure in name resolution 13 Contacting host: www.doi2bib.org:443 14 open-network-stream: www.doi2bib.org/443 Temporary failure in name r= esolution 15 Contacting host: doi2bib.org:80 Line nos. 1 and 2 are from url.el requests. 3--6 and 11--12 is from connection to search.brave.com from eww for an internet search. I cannot say with confidence but 15 should be when I opened doi2bib.org in eww once it became obvious that url.el will keep on failing... >> I am not sure how long this failing Emacs instance will fail but if it >> helps, I can try to do some debugging on my end as well. > > AFAICT once it happens it doesn't fix itself: the DNS server used by > your Emacs process is "stuck" and doesn't pay attention to > /etc/resolv.conf, so it "gets fixed" if you happen to be connected on > a network where the DNS server that Emacs tries to contact is available. Your analysis seems to be correct. Now that I'm back on the Ethernet connection, Emacs can happily make all the network requests its heart desires.=20=20 But I seem to recall a similar failure back when you initially spoke of this issue (even before opening this bug report) and I think I solved it by opening the failing webpage in eww, which is why I tried this again today for doi2bib.org. It seemed to have worked once i.e., eww opened the website but failed again when I tried a second time. So for all I know, it could have been sheer luck. >> I tried to use tcpdump but the manpage seems to suggest that there is >> no way to filter network requests made by a particular process, and >> I see too many junk requests to isolate the traffic that matters. > > I used a filter which only kept packets sent to a DNS port (port 53) and > that was sufficient to see requests to the "wrong" DNS server (e.g. the > one you use when your machine is connected via Ethernet, even though > the machine is currently connected via wifi) and to confirm that those > requests are correlated with the operation I perform in Emacs. That sounds a bit too involved for me currently. If I get more time (this might not happen until January) and if the bug shows its face itself again, I will try to look into this in greater detail to help squash this bug.