* bug#53070: 27.2; Message "Server closed connection" not verbose enough
@ 2022-01-07 9:08 Tim Landscheidt
2022-01-07 9:35 ` Robert Pluim
2022-01-07 16:13 ` Eric Abrahamsen
0 siblings, 2 replies; 6+ messages in thread
From: Tim Landscheidt @ 2022-01-07 9:08 UTC (permalink / raw)
To: 53070
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.)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#53070: 27.2; Message "Server closed connection" not verbose enough
2022-01-07 9:08 bug#53070: 27.2; Message "Server closed connection" not verbose enough Tim Landscheidt
@ 2022-01-07 9:35 ` Robert Pluim
2022-01-14 8:04 ` Lars Ingebrigtsen
2022-01-07 16:13 ` Eric Abrahamsen
1 sibling, 1 reply; 6+ messages in thread
From: Robert Pluim @ 2022-01-07 9:35 UTC (permalink / raw)
To: Tim Landscheidt; +Cc: 53070
>>>>> On Fri, 07 Jan 2022 09:08:28 +0000, Tim Landscheidt <tim@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
--
^ permalink raw reply related [flat|nested] 6+ messages in thread* bug#53070: 27.2; Message "Server closed connection" not verbose enough
2022-01-07 9:08 bug#53070: 27.2; Message "Server closed connection" not verbose enough Tim Landscheidt
2022-01-07 9:35 ` Robert Pluim
@ 2022-01-07 16:13 ` Eric Abrahamsen
2022-01-07 22:12 ` Tim Landscheidt
1 sibling, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2022-01-07 16:13 UTC (permalink / raw)
To: Tim Landscheidt; +Cc: 53070
Tim Landscheidt <tim@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#53070: 27.2; Message "Server closed connection" not verbose enough
2022-01-07 16:13 ` Eric Abrahamsen
@ 2022-01-07 22:12 ` Tim Landscheidt
2022-01-07 22:41 ` Eric Abrahamsen
0 siblings, 1 reply; 6+ messages in thread
From: Tim Landscheidt @ 2022-01-07 22:12 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: 53070
Eric Abrahamsen <eric@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 :-).
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#53070: 27.2; Message "Server closed connection" not verbose enough
2022-01-07 22:12 ` Tim Landscheidt
@ 2022-01-07 22:41 ` Eric Abrahamsen
0 siblings, 0 replies; 6+ messages in thread
From: Eric Abrahamsen @ 2022-01-07 22:41 UTC (permalink / raw)
To: Tim Landscheidt; +Cc: 53070
Tim Landscheidt <tim@tim-landscheidt.de> writes:
> Eric Abrahamsen <eric@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-14 8:04 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-01-07 9:08 bug#53070: 27.2; Message "Server closed connection" not verbose enough Tim Landscheidt
2022-01-07 9:35 ` Robert Pluim
2022-01-14 8:04 ` Lars Ingebrigtsen
2022-01-07 16:13 ` Eric Abrahamsen
2022-01-07 22:12 ` Tim Landscheidt
2022-01-07 22:41 ` Eric Abrahamsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).