GNU bug report logs -
#53070
27.2; Message "Server closed connection" not verbose enough
Previous Next
Reported by: Tim Landscheidt <tim <at> tim-landscheidt.de>
Date: Fri, 7 Jan 2022 09:09:02 UTC
Severity: normal
Found in version 27.2
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53070 in the body.
You can then email your comments to 53070 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
:
bug#53070
; Package
emacs,gnus
.
(Fri, 07 Jan 2022 09:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tim Landscheidt <tim <at> tim-landscheidt.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
.
(Fri, 07 Jan 2022 09:09:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I have a number of IMAP, POP3 and NNTP servers configured.
When everything is fine, gnus-group-get-new-news will output
the messages:
| Checking new news...
| Reading active file from private via nnml...
| Reading incoming mail from pop... [3 times]
| Reading incoming mail from file...
| nnml: Reading incoming mail (no new mail)...done
| Reading active file from private via nnml...done
| Reading active file from archive via nnfolder...done
| Reading active file via nndraft...done
| Checking new news...done
From time to time, there will be a hiccup somewhere, and the
messages instead will read:
| Checking new news...
| Opening connection to imap.gmail.com via tls...
| Opening connection to imap.gmail.com...done
| Reading active file from private via nnml...
| Reading incoming mail from pop...
| pop3 retrieved 0KB (0%) [14 times]
| pop3 retrieved 16KB (17%) [10 times]
| pop3 retrieved 32KB (35%) [20 times]
| pop3 retrieved 49KB (53%) [10 times]
| pop3 retrieved 65KB (71%) [10 times]
| pop3 retrieved 81KB (89%) [8 times]
| pop3 retrieved 91KB (100%)
| Wrote /path/to/nnml/file
| Reading incoming mail from pop... [2 times]
| Reading incoming mail from file...
| nnml: Reading incoming mail (1 new)...done
| Reading active file from private via nnml...done
| Reading active file from archive via nnfolder...done
| apply: Server closed connection
Now "Server closed connection" is an error message defined
for IMAP /and/ NNTP servers, and I have configured more than
one NNTP server as well. So I had to set
nntp-record-commands to t and look in *nntp-log*'s:
| 20220106T154438.490 news.gmane.io MODE READER
| 20220106T154508.531 news.gmane.io *** CONNECTION LOST ***
| 20220106T154511.955 news.gmane.io MODE READER
| 20220106T154541.984 news.gmane.io *** CALLED nntp-report ***
to /assume/ that the error occurs while Gnus is trying to
talk to news.gmane.io.
It would be more helpful if the error message read "Server
news.gmane.io closed connection" or, to avoid any ambiguity,
"NNTP server news.gmane.io closed connection".
(Side note: If such a hiccup happens, it sometimes appears
that the *Group* buffer is not updated with regard to number
of unread messages per group, etc. for /other/ servers that
were successfully contacted. I don't know if Gnus is more
aggressive than it needs to be here; if it encounters an er-
ror when trying to contact a POP3 server, it will just ask
nicely and continue on.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
:
bug#53070
; Package
emacs,gnus
.
(Fri, 07 Jan 2022 09:36:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 53070 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 07 Jan 2022 09:08:28 +0000, Tim Landscheidt <tim <at> tim-landscheidt.de> said:
Tim> Now "Server closed connection" is an error message defined
Tim> for IMAP /and/ NNTP servers, and I have configured more than
Tim> one NNTP server as well. So I had to set
Tim> nntp-record-commands to t and look in *nntp-log*'s:
Someone hasn't applied "Robert's rules for debuggability", which
state: "All log messages must be unique" :-)
Tim> | 20220106T154438.490 news.gmane.io MODE READER
Tim> | 20220106T154508.531 news.gmane.io *** CONNECTION LOST ***
Tim> | 20220106T154511.955 news.gmane.io MODE READER
Tim> | 20220106T154541.984 news.gmane.io *** CALLED nntp-report ***
Tim> to /assume/ that the error occurs while Gnus is trying to
Tim> talk to news.gmane.io.
Untested patch below.
Tim> It would be more helpful if the error message read "Server
Tim> news.gmane.io closed connection" or, to avoid any ambiguity,
Tim> "NNTP server news.gmane.io closed connection".
Tim> (Side note: If such a hiccup happens, it sometimes appears
Tim> that the *Group* buffer is not updated with regard to number
Tim> of unread messages per group, etc. for /other/ servers that
Tim> were successfully contacted. I don't know if Gnus is more
Tim> aggressive than it needs to be here; if it encounters an er-
Tim> ror when trying to contact a POP3 server, it will just ask
Tim> nicely and continue on.)
Thatʼs a separate issue. My connections are reliable enough that I
donʼt see this.
diff --git i/lisp/gnus/nnimap.el w/lisp/gnus/nnimap.el
index fd6e3c0ccf..710b08b9da 100644
--- i/lisp/gnus/nnimap.el
+++ w/lisp/gnus/nnimap.el
@@ -245,7 +245,7 @@ nnimap-retrieve-headers
(nnimap-header-parameters))
t)
(unless (process-live-p (get-buffer-process (current-buffer)))
- (error "Server closed connection"))
+ (error "IMAP server %S closed connection" nnimap-address))
(nnimap-transform-headers)
(nnheader-remove-cr-followed-by-lf))
(insert-buffer-substring
diff --git i/lisp/gnus/nntp.el w/lisp/gnus/nntp.el
index 038a6d0625..df4c0068e3 100644
--- i/lisp/gnus/nntp.el
+++ w/lisp/gnus/nntp.el
@@ -305,7 +305,7 @@ nntp-send-string
(nntp-record-command string))
(process-send-string process (concat string nntp-end-of-line))
(or (memq (process-status process) '(open run))
- (nntp-report "Server closed connection")))
+ (nntp-report "NNTP server %S closed connection" nntp-address)))
(defun nntp-record-command (string)
"Record the command STRING."
@@ -370,7 +370,7 @@ nntp-wait-for
(nntp-snarf-error-message)
nil))
((not (memq (process-status process) '(open run)))
- (nntp-report "Server closed connection"))
+ (nntp-report "NNTP server %S closed connection" nntp-address))
(t
(goto-char (point-max))
(let ((limit (point-min))
@@ -1435,7 +1435,7 @@ nntp-accept-process-output
;; be the process's former output buffer (i.e. now killed)
(or (and process
(memq (process-status process) '(open run)))
- (nntp-report "Server closed connection")))))
+ (nntp-report "NNTP server %S closed connection" nntp-address)))))
(defun nntp-accept-response ()
"Wait for output from the process that outputs to BUFFER."
@@ -1454,7 +1454,7 @@ nntp-possibly-change-group
(when group
(let ((entry (nntp-find-connection-entry nntp-server-buffer)))
(cond ((not entry)
- (nntp-report "Server closed connection"))
+ (nntp-report "NNTP server %S closed connection" nntp-address))
((not (equal group (caddr entry)))
(with-current-buffer (process-buffer (car entry))
(erase-buffer)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
:
bug#53070
; Package
emacs,gnus
.
(Fri, 07 Jan 2022 16:14:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 53070 <at> debbugs.gnu.org (full text, mbox):
Tim Landscheidt <tim <at> tim-landscheidt.de> writes:
[...]
> It would be more helpful if the error message read "Server
> news.gmane.io closed connection" or, to avoid any ambiguity,
> "NNTP server news.gmane.io closed connection".
Thank you for reporting this, and I think Robert's patch would be very
welcome.
> (Side note: If such a hiccup happens, it sometimes appears
> that the *Group* buffer is not updated with regard to number
> of unread messages per group, etc. for /other/ servers that
> were successfully contacted. I don't know if Gnus is more
> aggressive than it needs to be here; if it encounters an er-
> ror when trying to contact a POP3 server, it will just ask
> nicely and continue on.)
How recent is your Emacs? In 032969e8 (end of October) I put in a patch
which switched NNTP failures from raising an error -- which interrupted
the whole update process -- to simply reporting the failure. What you
describe sounds like the behavior I'd observed before making that
change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
:
bug#53070
; Package
emacs,gnus
.
(Fri, 07 Jan 2022 22:13:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 53070 <at> debbugs.gnu.org (full text, mbox):
Eric Abrahamsen <eric <at> ericabrahamsen.net> wrote:
> […]
>> (Side note: If such a hiccup happens, it sometimes appears
>> that the *Group* buffer is not updated with regard to number
>> of unread messages per group, etc. for /other/ servers that
>> were successfully contacted. I don't know if Gnus is more
>> aggressive than it needs to be here; if it encounters an er-
>> ror when trying to contact a POP3 server, it will just ask
>> nicely and continue on.)
> How recent is your Emacs? In 032969e8 (end of October) I put in a patch
> which switched NNTP failures from raising an error -- which interrupted
> the whole update process -- to simply reporting the failure. What you
> describe sounds like the behavior I'd observed before making that
> change.
27.2; I agree with your reasoning and look forward to your
patch trickling down to Fedora :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
:
bug#53070
; Package
emacs,gnus
.
(Fri, 07 Jan 2022 22:42:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 53070 <at> debbugs.gnu.org (full text, mbox):
Tim Landscheidt <tim <at> tim-landscheidt.de> writes:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> wrote:
>
>> […]
>
>>> (Side note: If such a hiccup happens, it sometimes appears
>>> that the *Group* buffer is not updated with regard to number
>>> of unread messages per group, etc. for /other/ servers that
>>> were successfully contacted. I don't know if Gnus is more
>>> aggressive than it needs to be here; if it encounters an er-
>>> ror when trying to contact a POP3 server, it will just ask
>>> nicely and continue on.)
>
>> How recent is your Emacs? In 032969e8 (end of October) I put in a patch
>> which switched NNTP failures from raising an error -- which interrupted
>> the whole update process -- to simply reporting the failure. What you
>> describe sounds like the behavior I'd observed before making that
>> change.
>
> 27.2; I agree with your reasoning and look forward to your
> patch trickling down to Fedora :-).
Ouch! Well, it will get to you eventually.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org
:
bug#53070
; Package
emacs,gnus
.
(Fri, 14 Jan 2022 08:05:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 53070 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Someone hasn't applied "Robert's rules for debuggability", which
> state: "All log messages must be unique" :-)
I've applied the error message patch to Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
53070 <at> debbugs.gnu.org and Tim Landscheidt <tim <at> tim-landscheidt.de>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 14 Jan 2022 08:07:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 11 Feb 2022 12:24:12 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 46 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.