GNOME Bugzilla – Bug 720154
Silently recover from "Connection reset by peer" error
Last modified: 2014-04-30 13:30:43 UTC
Periodically, when trying to post a message to an NNTP group the posting will fail and I will get this dialog: An error occurred while sending. How do you want to proceed? The reported error was "Posting failed: TCP connection reset by peer". Continue Editing Save to Outbox Try Again And unfortunately, the only thing one can do at this point is to restart evolution and try again. Going back to editing the message and trying to send again results in a never ending "Sending message". So restarting it all one can do. But even that is not straightforward as it requires one to: 1. Save as a draft 2. Restart evolution 3. Retrieve message from drafts folder (i.e. edit as new message) 4. Remove the invalid (folder://local/Drafts) Post To: target in the message opened in step 3 5. Open up the NNTP folder you want to post to 6. Start a new message 7. Copy and paste (the cryptic folder name) from the Post To: in the message opened in step 6 to the Post To: in the message opened in step 3. 8. Send. Clearly fixing the root cause (dealing with the TCP reset) would eliminate the 8 steps it takes to work around the problem, but even still, those 8 steps are nothing less than painful. And why do NNTP group names have to be so cryptic? I.e.: folder://1383652687.29482.30@pc.example.com/news.group.name
Is there anything that can be done about this one? This is really annoying. It practically means that one has to restart Evolution for every NNTP message they want to send. Surely handling a TCP RESET by simply reopening the connection is easy enough to do -- for somebody that knows that code that is. :-) I'd be happy to submit a patch but the ramp up to figuring out where and how to apply that would be prohibitive I fear. I'd also love to upgrade to 3.10 in Fedora 20 to at least see if this problem exists there but unfortunately there are show-stopper bugs in Fedora 20 that to my knowledge have not been fixed yet given that the bugs that I have opened on them have not had any activity.
I thought that 3.8.4 will behave better, at least according to bug #692904, but it wasn't enough probably. I see more more-or-less related changes for 3.10.0 in NNTP code, thus it would be appreciated to test with it. If your show-stopper bugs are evolution-related, could you be more specific, please? The best to update to 3.10.4, which is part of updates-testing in Fedora 20 since today (as 3.10.4 was released only yesterday).
(In reply to comment #2) > > If your show-stopper bugs are evolution-related, could you be more specific, > please? They are not, for the most part. There is one about the message summary colour changing filter regressing and not working (bug 720751), and while strictly not a show-stopper, it's just one more reason to not use FC20. That bug does say it's fixed on master and gnome-3-10 but I'm not sure if either of those have resulted in an update in F20 yet. Coloring is how I can quickly scan my INBOX and find the important stuff. FWIW, I tried to use scoring and vfolders for that but that doesn't work either. I'm not sure why, but messages which are below the score for the vfolder's conditions seem to show up in it anyway. > The best to update to 3.10.4, which is part of updates-testing in > Fedora 20 since today (as 3.10.4 was released only yesterday). Ahh. At least the colouring might be fixed. I'm trying to remember what else about F20 was holding me back. Of course there is the big bluetooth-HSF/HPF kafuffle but I don't use BT HSP/HFP on this machine (I do my other machine though). There was also a gscan2pdf (and/or perl_ regression but maybe that's been fixed also. Perhaps it's time to give F20 another try...
Ahhh. Now I remember. The big show-stopper for F20 on this machine is it's multi-screen copy/paste regression. That is, you cannot copy on (say) screen :0.1 and then paste on screen :0.0. Just filed that as https://bugzilla.redhat.com/show_bug.cgi?id=1067125 But given that I have evolution open on one screen and most of my other applications on another screen, it means no copy/paste to from e-mail which is quite crippling. :-(
So, this problem does still exist in 3.10.4 as it has been packaged by in F20. But given the serious amount of pain this causes, can we get fixing it prioritized?
I sometimes get "Connection reset by peer" on some of my IMAP servers too. handling of this issue in more general way (not only for NNTP or IMAP) would be better. I have it in my ToDo, though it's getting lengthy these days.
I finished the change for IMAPx, it'll be better divided into two commits, to not interleave NNTP and IMAPx changes (the IMAPx are quite large). I'll update the bug when I figure out required changes in the NNTP code (I didn't look into it yet), though I'm not sure how to properly test it, aka on which server in a way of not spamming any folder there. Created commit 8f92693 in eds master (3.13.2+) [1] Created commit 8c173e9 in eds evolution-data-server-3-12 (3.12.2+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=8f92693
Interesting, the change in NNTP was even simpler than in IMAPx (significantly simpler). I was able to reproduce "Broken Pipe" and "Connection reset by peer" errors when sending a message into NNTP server, but when I applied [2], I've sent the message properly, with noticed reconnect in the background. All that was because the used nntp_stream was a stale connection, which was abandoned before it had been used. Created commit 11691af in eds master (3.13.2+) [2] Created commit 31bd912 in eds evolution-data-server-3-12 (3.12.2+) [2] https://git.gnome.org/browse/evolution-data-server/commit/?id=11691af