GNU bug report logs - #53070
27.2; Message "Server closed connection" not verbose enough

Previous Next

Packages: emacs, gnus;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.2; Message "Server closed connection" not verbose enough
Date: Fri, 07 Jan 2022 09:08:28 +0000
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):

From: Robert Pluim <rpluim <at> gmail.com>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 53070 <at> debbugs.gnu.org
Subject: Re: bug#53070: 27.2; Message "Server closed connection" not verbose
 enough
Date: Fri, 07 Jan 2022 10:35:14 +0100
>>>>> 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):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 53070 <at> debbugs.gnu.org
Subject: Re: bug#53070: 27.2; Message "Server closed connection" not verbose
 enough
Date: Fri, 07 Jan 2022 08:13:42 -0800
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):

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 53070 <at> debbugs.gnu.org
Subject: Re: bug#53070: 27.2; Message "Server closed connection" not verbose
 enough
Date: Fri, 07 Jan 2022 22:12:09 +0000
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):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 53070 <at> debbugs.gnu.org
Subject: Re: bug#53070: 27.2; Message "Server closed connection" not verbose
 enough
Date: Fri, 07 Jan 2022 14:41:13 -0800
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):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 53070 <at> debbugs.gnu.org, Tim Landscheidt <tim <at> tim-landscheidt.de>
Subject: Re: bug#53070: 27.2; Message "Server closed connection" not verbose
 enough
Date: Fri, 14 Jan 2022 09:04:34 +0100
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.