Gnus development mailing list
 help / color / mirror / Atom feed
* nnimap process die repeatedly
@ 2020-09-08 12:57 Juan José García-Ripoll
  2020-09-28 22:57 ` Eric Abrahamsen
  0 siblings, 1 reply; 2+ messages in thread
From: Juan José García-Ripoll @ 2020-09-08 12:57 UTC (permalink / raw)
  To: ding

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?

Juanjo

-- 
Juan José García Ripoll
http://juanjose.garciaripoll.com
http://quinfog.hbar.es



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: nnimap process die repeatedly
  2020-09-08 12:57 nnimap process die repeatedly Juan José García-Ripoll
@ 2020-09-28 22:57 ` Eric Abrahamsen
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Abrahamsen @ 2020-09-28 22:57 UTC (permalink / raw)
  To: Juan José García-Ripoll; +Cc: ding

Juan José García-Ripoll <juanjose.garciaripoll@gmail.com> 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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-28 22:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-08 12:57 nnimap process die repeatedly Juan José García-Ripoll
2020-09-28 22:57 ` Eric Abrahamsen

Gnus development mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/ding

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 ding ding/ http://inbox.vuxu.org/ding \
		ding@inbox.vuxu.org
	public-inbox-index ding

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.emacs.gnus.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git