How can I interrupt feed update when it's stuck (without restarting emacs)? about elfeed HOT 6 CLOSED

As a follow-up, I built in gnutls support to increase the number of feeds fetched in parallel to 4, so now it gets down to the message "0 feeds pending, 1 in process ...".

I don't know how to find out which feed is the problem. If it helps, I'm also seeing a couple messages like this:

gnutls.c: [1] There was an error parsing the OCSP response: ASN1 parser: Error in DER parsing..
gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated.

so this might explain why updating gets stuck.

from elfeed.

You've got the right idea: fetching feeds in parallel generally resolves
the hangup. Under some conditions, like those gnutls failures you're
seeing, url-retrieve never responds to the callback to report the error,
so Elfeed will wait forever on these stuck connections. I consider this
a bug in url-retrieve. The work-around for this issue would be to launch
a timeout timer in parallel with url-retrieve to clean up when
url-retrieve doesn't respond, but I haven't bothered to do this yet.

As a short-term solution I just added an elfeed-unjam command. It will
clear out all active connections in case they get stuck like this.

from elfeed.

elfeed-unjam works great, thanks a lot.

from elfeed.

Hey guys, I'd be glad to know :-

1. Are there any further updates to this issue? Elfeeds still hangs up emacs regularly for me..
2. if emacs is completely stuck, while updating elfeed : how is the elfeed-unjam command applied ?

from elfeed.

When it completely locks up it's usually a DNS issue. Currently Emacs
resolves DNS synchronously, so if you're talking to a crappy DNS server
(i.e. your corporate DNS server at work) you'll experience frequent
lockups. (On Windows it's even worse, since TCP connections are also
established synchronously.) Emacs should be switching to asynchronous
DNS resolution in a future release, which will hopefully fix this
problem:

https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01348.html

You should be able to use C-g to break out, though in my experience it
can be slow to respond. Using C-g while url-queue is active will usually
confuse the url-queue queue, which is where elfeed-unjam comes into play
(resets url-queue when it gets itself into a bad state).

from elfeed.

Christopher, thanks for your reply. Should using emacs from within Linux
on virtualbox in windows make a difference, i.e enable emacs to
establish TCP connections asynchronously ?

I have just setup emacs, compiling from source in Lubuntu. The fonts,
theme and the entire feel of orgmode in emacs is quite different, not to
mention several 'bugs' like table mis-alignments have vanished !

NOte: As such, it does seem to make a difference. I tried to load an
opml file into elfeed on my emacs in windows, several times, and it
Never loaded. HOwever, it happened perfectly the very first time on Lubuntu.

On Wednesday 09 March 2016 08:18 PM, Christopher Wellons wrote:

When it completely locks up it's usually a DNS issue. Currently Emacs
resolves DNS synchronously, so if you're talking to a crappy DNS server
(i.e. your corporate DNS server at work) you'll experience frequent
lockups. (On Windows it's even worse, since TCP connections are also
established synchronously.) Emacs should be switching to asynchronous
DNS resolution in a future release, which will hopefully fix this
problem:

https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01348.html

You should be able to use C-g to break out, though in my experience it
can be slow to respond. Using C-g while url-queue is active will usually
confuse the url-queue queue, which is where elfeed-unjam comes into play
(resets url-queue when it gets itself into a bad state).

—
Reply to this email directly or view it on GitHub
#33 (comment).

from elfeed.