From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58520: Persistent failure to DNS-lookup hostname Date: Tue, 05 Sep 2023 13:06:11 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9101"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Paul Eggert To: 58520@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 05 19:07:24 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 1qdZWN-00029M-Pc for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Sep 2023 19:07:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdZW3-0004NB-Ni; Tue, 05 Sep 2023 13:07:03 -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 1qdZW2-0004Ml-7r for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2023 13:07:02 -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 1qdZW2-000735-01 for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2023 13:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qdZW2-0003pr-C8 for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2023 13:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Sep 2023 17:07:02 +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.169393358414690 (code B ref 58520); Tue, 05 Sep 2023 17:07:02 +0000 Original-Received: (at 58520) by debbugs.gnu.org; 5 Sep 2023 17:06:24 +0000 Original-Received: from localhost ([127.0.0.1]:58775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdZVQ-0003oq-9V for submit@debbugs.gnu.org; Tue, 05 Sep 2023 13:06:24 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4118) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdZVM-0003ob-SU for 58520@debbugs.gnu.org; Tue, 05 Sep 2023 13:06:23 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3677A444676; Tue, 5 Sep 2023 13:06:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1693933572; bh=p25nyfTEidxb3RpdPMwW+uO0Qh0XKMvaR3s3XELpJNs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HF2JvOA47i0V5ggZLIgv37KZRr8g/CVdcJ1F+G6+ljlYTH+VXL8c78j2OPSKyoNxL qTysSyCciMf6oY9FMQ2bkcJwBSHwXBlkKsMqasEqQCBWCSS7SVwtUiBsgtW21bBdi2 RYP4+CI1TV/Q2z5rgtpmsENLXM8Q56E/hwRLHpMxq4IPkHHsI3YDDTuPbz6mPeEIVy XvzeJVnLFJ9VVcNzITUyMwGeqZZT/4RIys80yr5Tl3j81l4MWLxN+VECCaEflTCb5t giLVLUAKHyaYvfpMDKlzdrcvYM64qvjf9CIx03O+/JVKzZBx4rMbpcWImzMwZJIG7S xqlMBt2dRj6xA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4445244466F; Tue, 5 Sep 2023 13:06:12 -0400 (EDT) Original-Received: from pastel (69-165-136-223.dsl.teksavvy.com [69.165.136.223]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 21CE812023C; Tue, 5 Sep 2023 13:06:12 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Fri, 14 Oct 2022 12:20:52 -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:269384 Archived-At: FWIW, I've seen this bug on a somewhat regular basis. I have not been able to reproduce it: it seems to show up only after Emacs has been in use for several days. I did confirm that calling `M-: (res-init) RET` does work around the problem in the sense that the Emacs session can then successfully perform DNS lookups again. [ `res-init` is a little DEFUN I added which just calls `res_init`. ] So, as far as I can tell, the problem is that glibc or Emacs somehow get into a state where the automatic decision to refresh the info about the address of the DNS server doesn't work any more. Stefan Stefan Monnier [2022-10-14 12:20:52] wrote: > Package: Emacs > > > [ I see that my original email was sent to emacs-devel, but I think > bug-gnu-emacs is a better place for that. ] > > My Gnus session (a separate Emacs session I use specifically to run > Gnus) occasionally gets into a state where it insists that my mail > server's DNS name isn't found. All(?) other processes on the machine > keep happily resolving hostname, so the problem is specific to > this process. > > The problem just reappeared today and thanks to the help I got last time > I managed to diagnose it a bit better: > > - Lars asked if it only affect IMAP: nope, it affects more than just > IMAP. Simple tests suggest it affects all DNS lookups performed by > that Emacs process. > - Madhu suggested the problem was related to commit 93bf7d52841c60ff and > might be linked to a lack of call to `res_init`. For some stupid > reason I wasn't able to add an ELisp primitive that lets me call > `res_init` manually to verify this hypothesis, but I now figured what > was my mistake, so I should be able to try `M-: (res-init) RET` next time > to confirm that it works around the problem. > - Robert's suggestion to use `tcpdump` showed that the reason this Emacs > process gets DNS lookup failures is simply that it queries the DNS > server at 192.168.1.1 which is the server I was using yesterday (and > to which I currently don't have access) rather than the one I'm using > now. IOW, it strongly suggests that the problem would be solved by > calling `res_init`. > > [Glibc bug 984](https://sourceware.org/bugzilla/show_bug.cgi?id=984) > seems relevant. According to this, calling `res_init` should not be > necessary any more. Indeed, if I start Emacs, use > `make-network-process`, then change `/etc/resolv.conf`, then call > `make-network-process` again, tcpdump shows clearly that the Emacs > session has noticed the change in `/etc/resolv.conf`. I tried this same > test from a fresh new Gnus session, and that also works fine. > > So it's still a mystery why my Gnus session sometimes gets into a state > where it apparently stops paying attention to changes in > `/etc/resolv.conf`. The above bug 984 mentions that glibc's "auto > reload" of `/etc/resolv.conf` is prevented in case the application has > modified `_res` manually, but I can't see any place where we do that. > Could it be that some of the libraries we link with can sometimes > manually modify `_res`? > > > Stefan