bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g n


From: N. Jackson
Subject: bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits
Date: Fri, 29 Sep 2017 13:27:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

At 08:20 -0700 on Friday 2017-09-29, Eric Abrahamsen wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> Does gnus-group-get-new-news use any of the url-* functions? If
>> so, perhaps try setting url-asynchronous to nil when fetching
>> news, to see if that solves the problem. Or maybe even build
>> Emacs with HAVE_GETADDRINFO_A undefined, and see if that helps.
>
> FWIW, I would put money on `nntp-open-connection' being the
> culprit, specifically the call to `open-network-stream'.

Eli and Eric, than you for these suggestions. I will have a look
in these directions the next time Gnus "breaks". (I hadn't yet
read them when I wrote the report below.)

Gnus "broke" again this morning. (It seems to break in the morning
when I switch it to the "plugged" state after I've have it
"unplugged" over night for offline reading.)

Unfortunately there are at least two different problems, although
they might be related.

(The following all applies to the Emacs session this morning with
Gnus in it's "broken" state.)

I set `debug-on-error' and got the following (redacted) backtrace
when fetching mail/news:

  Debugger entered--Lisp error: (error "something.com/443 Name or service not 
known")
    signal(error ("something.com/443 Name or service not known"))
    nnrss-fetch("https://something.com/boards/forums/support.246/index.rss";)
    nnrss-check-group("Something Forums: Support" "")
    nnrss-retrieve-groups(("Something Forums: Support" "Something Forums: 
Software" "Something Forums: Something Else" "Something Forums: Discussions" 
"Something Forums: News") "")
    gnus-retrieve-groups(("Something Forums: Support" "Something Forums: 
Software" "Something Forums: Something Else" "Something Forums: Discussions" 
"Something Forums: News") (nnrss ""))
    gnus-read-active-file-2(("Something Forums: Support" "Something Forums: 
Software" "Something Forums: Something Else" "Something Forums: Discussions" 
"Something Forums: News") (nnrss ""))
    gnus-read-active-for-groups((nnrss "") (("nnrss:Something Forums: Support" 
3 ((1 . 9)) ((unexist) (seen (1 . 6))) (nnrss "")) ("nnrss:Something Forums: 
Software" 3 ((1 . 1)) ((unexist) (seen 1)) (nnrss "")) ("nnrss:Something 
Forums: Something Else" 3 ((1 . 117)) ((unexist) (seen (1 . 56) (67 . 117))) 
(nnrss "")) ("nnrss:Something Forums: Discussions" 3 ((1 . 857)) ((unexist) 
(seen (1 . 245) (421 . 857))) (nnrss "")) ("nnrss:Something Forums: News" 3 ((1 
. 672)) ((unexist) (seen (1 . 168) (282 . 672))) (nnrss ""))) nil)
    gnus-get-unread-articles(nil nil nil)
    gnus-group-get-new-news(nil)
    funcall-interactively(gnus-group-get-new-news nil)
    call-interactively(gnus-group-get-new-news nil nil)
    command-execute(gnus-group-get-new-news)

There was no problem with the reported URl; I could open it fine
in a web browser. I changed the "level" of these RSS groups so
that Gnus does not try to check them when it fetches mail and
news. After doing that, I no longer end up in the debugger when
fetching mail/news with `debug-on-error' set. That was the first
problem.

However, fetching mail/news was still broken -- no hang this time,
just nothing seeming to happen. And the *Server* buffer was messed
up as I previously described:

At 10:13 -0400 on Tuesday 2017-09-26, N. Jackson wrote:
>
> The problem can be easily seen in the *Server* buffer. All my
> nntp servers are broken.
>
> - The nntp servers that are managed by the Agent are in an
>   "offline" state even though Gnus is currently plugged (and I
>   have a good Internet connection), and the `O', `C' and `R'
>   (open, close, and reset all) commands have not effect. (Toggling
>   the plugged/unplugged state a few times hasn't changed this
>   brokenness.)
>
> - The nntp servers that are not managed by the Agent are in a
>   "denied" state and the `O', `C' and `R' (open, close, and reset
>   all) commands have not effect.

It almost seems as if Gnus is in an "unplugged" state even though
in the mode line it says that it's "plugged". (Toggling the
plugged/unplugged state so that the mode line says it's
"unplugged" doesn't help though.)

One reason why I think Gnus is actually "unplugged" is that when I
enter a news group that is managed by the Agent when Gnus is
"unplugged", the *Summary* buffer is displayed almost instantly.
In contrast when Gnus is not in a "broken" state and is "plugged",
loading the *Summary* buffer is slow as Gnus will retrieve headers
over the Internet,

A second reason why I think Gnus is actually "unplugged" is that
there are lines in news group *Summary* buffers like

  - .│0.0k│1969-12-31 19:00│ ▣ Gnus Agent               [Undownloaded article 
218857]

which I would normally only see when Gnus is "unplugged".

I have now restarted Emacs to get Gnus back into a working state
-- I have to get real work done. I will report more when I have
time to investigate a "broken" instance of Gnus more thoroughly.

N.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]