From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29288 invoked from network); 4 Jul 2023 17:03:11 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 4 Jul 2023 17:03:11 -0000 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGjQQ-0003la-Qp; Tue, 04 Jul 2023 13:02:50 -0400 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 1qGjQP-0003kt-Hh for info-gnus-english@gnu.org; Tue, 04 Jul 2023 13:02:49 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGjQN-0007Xu-TU for info-gnus-english@gnu.org; Tue, 04 Jul 2023 13:02:49 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qGjQH-0000Gr-9w for info-gnus-english@gnu.org; Tue, 04 Jul 2023 19:02:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: Eric Abrahamsen Subject: Re: Gnus fetch freezes emacs Date: Tue, 04 Jul 2023 10:02:34 -0700 Message-ID: <87v8ezehjp.fsf@ericabrahamsen.net> References: <87sfa9nhp4.fsf@gmail.com> <87ttuoeoej.fsf@gmx.net> <87mt0e1h0u.fsf@gmail.com> <87h6qlsw3n.fsf@ericabrahamsen.net> <87o7ktjgmw.fsf@ucl.ac.uk> <87zg4dq7ed.fsf@ericabrahamsen.net> <87wmzfx69o.fsf@gmx.net> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:CRwaVGwGggxHIof53aKB4rVKOlY= Received-SPF: pass client-ip=116.202.254.214; envelope-from=gegu-info-gnus-english@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Stephen Berman writes: > On Mon, 03 Jul 2023 09:36:26 -0700 Eric Abrahamsen wrote: > >> Eric S Fraga writes: >> >>> On Sunday, 2 Jul 2023 at 16:59, Eric Abrahamsen wrote: >>>> If everyone's hitting this with NNTP servers, you can set >>>> `nntp-connection-timeout' to a number of seconds. It is nil by default, >>>> which I guess would result in permanent hangs. > > Is this variable supposed to be set in the value of gnus-select-method? > For example, like this: > > (setq gnus-select-method '(nntp "news.gmane.io" > (nntp-connection-timeout 3))) It's a defvoo, so it can either be set globally, or as a server parameter. >>> So this works, in the sense that it stops me waiting forever... However, >>> it seems (early days yet) that when it fails to open the connection to >>> an NNTP server, it stops retrieving news and I have to hit 'g' again to >>> get the counts etc. updated for other servers. [...] > > That sounds basically like what the function I'm using in place of > gnus-group-get-new-news (see my first post in this thread) does. Could > such a function take effect if added to one of the server hook variables > nntp-server-opened-hook, nntp-server-action-alist or > nntp-open-connection-function? From the descriptions in the manual it > isn't clear to me. Or is there some better Gnus hook variable for this > purpose? If not could one be added? I'm not sure what function you mean. Eric F is just describing the unfortunate behavior of nntp-connection-timeout, which interrupts the entire fetching process when it hits the timeout. >> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we >> just recently reverted it. I have a more thorough fix in progress >> somewhere here, that would report a server connection failure without >> interrupting the rest of the servers, but it's not done yet. I've had >> very little time for coding recently, but will get to it At Some Point. >> >> Glad it's at least better than it was. I wonder if we should have some >> generous timeout set by default... > > It might make sense to continue this discussion in bug#52735. This doesn't seem like the same issue -- this problem is pretty well understood. Eric