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=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_LOW autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2892 invoked from network); 28 Sep 2020 22:58:06 -0000 Received: from lists1.math.uh.edu (129.7.128.208) by inbox.vuxu.org with ESMTPUTF8; 28 Sep 2020 22:58:06 -0000 Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.94) (envelope-from ) id 1kN25W-00H84J-8k; Mon, 28 Sep 2020 17:57:42 -0500 Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kN25Q-00H82N-KV for ding@lists.math.uh.edu; Mon, 28 Sep 2020 17:57:36 -0500 Received: from quimby.gnus.org ([95.216.78.240]) by mx2.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kN25O-00BgWH-Bg for ding@lists.math.uh.edu; Mon, 28 Sep 2020 17:57:36 -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=jdw72/KzU14eoPLxIa0fI7MYFqTRzuQ0Ci8cf2Hlpcw=; b=F3/AVBjnXbhFpPv9IBYDDT/uUi egHG3YJ0k5pZTW+rTzwnJOqFj00bGqUFrUjcsJFNiQ+XvpMp7ixxJceZgsfhVetq+0WBU5apqMgUP 5VJUZ6kNibcKAz9Vnma15EV/0c/DMOE2SAblgS9bjeP+AJAj5pkCi0fjK++BydhuSojM=; Received: from ericabrahamsen.net ([52.70.2.18] helo=mail.ericabrahamsen.net) by quimby with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kN25G-00045w-CB for ding@gnus.org; Tue, 29 Sep 2020 00:57:29 +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 03C71FA5B6; Mon, 28 Sep 2020 22:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1601333844; bh=jdw72/KzU14eoPLxIa0fI7MYFqTRzuQ0Ci8cf2Hlpcw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=VJ4hZZcLPcCWYIhztaeNOdbvheP5b2yAIxEeFkiHpDSuLtXzGplisTqn5JDYuh7ZI FY5iZbTaTJYU6vINanBdOEpSxlfQQ98dLjNpQAADgRODjoc7oaXkXzl765xeY3sscA 0VQQwkDeSaqhypy9ueb0aG6a4VdlO/IbrQE3iFNI= From: Eric Abrahamsen To: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Cc: ding@gnus.org Subject: Re: nnimap process die repeatedly References: <86v9go8lyt.fsf@csic.es> Date: Mon, 28 Sep 2020 15:57:22 -0700 In-Reply-To: <86v9go8lyt.fsf@csic.es> ("Juan =?utf-8?Q?Jos=C3=A9_Garc?= =?utf-8?Q?=C3=ADa-Ripoll=22's?= message of "Tue, 08 Sep 2020 14:57:46 +0200") Message-ID: <87r1qlh5m5.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 Juan Jos=C3=A9 Garc=C3=ADa-Ripoll writes: > Hi, > > I have set up nnimap successfully and was using it fine with 26.3. I've > since upgraded to 27.1 (last RC) and I see nnimap process dying > often. Sometimes it is not noticed, other times gnus complains and I > have to close and reopen the server. In both cases a new buffer with a > new number appended to it is created. As of today, 6 hours into my > working day, I have 26 buffers with the name " *nnimap" in it, all for > the same server. Is there any way to debug why this happens? Why are > buffers not reused or processes deleted when this happens? I'll look in to cleaning up the process buffers, but would you be willing to try something? Visit the nnimap.el source file, find the definition of `nnimap-open-connection-1' (probably line 439), go a couple lines down, and change this bit: (run-at-time (* 60 15) (* 60 15) to: (run-at-time (* 60 3) (* 60 3) (or otherwise something smaller) Then re-evaluate the function and run it for a day? nnimap processes ought to have TCP keepalive enabled, and also should be sending "NOOP" IMAP commands to the server on the timer specified by the number above. A shorter timer might solve your problem, in which case it might be useful to make this number user-configurable. But regardless, those dead process buffers shouldn't be left lying around. Eric