From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 8341 invoked from network); 20 Apr 2020 04:55:42 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with UTF8ESMTPZ; 20 Apr 2020 04:55:42 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.92.3) (envelope-from ) id 1jQOSU-0002nw-JF; Sun, 19 Apr 2020 23:55:02 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQOSP-0002lC-UK for ding@lists.math.uh.edu; Sun, 19 Apr 2020 23:54:57 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jQOSO-0005SL-2T for ding@lists.math.uh.edu; Sun, 19 Apr 2020 23:54:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sfdkTE/ZqPrvIud2A6/RKrq0KF79vRxHmVPoYorEEsA=; b=KdoBXB+wiL9xxJWme1quNEhwJf XLCoV1+2ioLG/1jNWAkxyz18l/WoJNuUZMUuAIsNFO4Y0q6q7HarhQG7GcP/eRrNG0EbE0llL/cvK cNvmdfJCuKbHBdD0G1gI96Ig5LP6Ut9Kt/jcf9h0lz37h4UdSTin5XvSu6/6p724BBg8=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jQOSG-0001SI-V8 for ding@gnus.org; Mon, 20 Apr 2020 06:54:51 +0200 Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 4045DFA099; Mon, 20 Apr 2020 04:54:46 +0000 (UTC) From: Eric Abrahamsen To: Robert Pluim Cc: Christian Barthel , ding@gnus.org Subject: Re: new wifi connection = nntp timeout = Emacs restart? References: <87sgh3coxn.fsf@ericabrahamsen.net> <87o8rogew7.fsf@barthel.ch> <87zhb7mlf0.fsf@ericabrahamsen.net> <87k12bm8it.fsf@ericabrahamsen.net> Date: Sun, 19 Apr 2020 21:54:44 -0700 In-Reply-To: <87k12bm8it.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sun, 19 Apr 2020 15:10:34 -0700") Message-ID: <87lfmqlpt7.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: Precedence: bulk Eric Abrahamsen writes: > Robert Pluim writes: > >>>>>>> On Sun, 19 Apr 2020 10:32:03 -0700, Eric Abrahamsen >> said: >> Eric> Yeah, I used to assume I was hallucinating, but it's been goin= g on for >> Eric> too long now. The rest of what you describe below is perfectly= "normal" >> Eric> for Gnus, and the same as what we all experience, but this res= tarting >> Eric> thing... Next time I switch networks (not all that often, thes= e days) >> Eric> I'll do some edebugging and try to open a more detailed bug re= port. >> >> I see this too. Every time I try to look at it, it=CA=BCs an issue >> somewhere deep in Emacs' networking code where it=CA=BCs trying to read >> from the network and failing, but not failing enough that it gets an >> error or a timeout. And then Real Life=E2=84=A2 intervenes and I *have* = to get >> Gnus working again. >> >> I=CA=BCve tried turning on tcp-keepalives, but that doesn=CA=BCt help ei= ther. > > I just started watching Emacs' nntp connections, and immediately noticed > that closing all servers ("z") and re-opening them ("g") does not kill > the previous connection, it just opens a new one, with it's own > keepalive timer. > > If I kill Gnus, it kills all the open connections, but maybe there's > something about switching networks that prevents it from killing the > connections? And then we try to use a stale connection? I will test > more. > > But doesn't it seem basically wrong that `gnus-close-server' on an nntp > server doesn't kill the network connection? It's "z" suspending Gnus that doesn't work, "C" on the nntp server in the *Server* buffer kills the connection correctly. Using "z" apparently does not set the `nntp-server-buffer' correctly -- the "(nntp-find-connection nntp-server-buffer)" call returns nil. One step at a time...