GNOME Bugzilla – Bug 551788
Hangs when network changes
Last modified: 2012-09-12 12:58:31 UTC
When going to a different place while the laptop is suspended and then connecting to a different wireless network on resume (while evo is running), evolution tries to look for new mail but does not succeed but instead simply wait forever on a response. In addition choosing File->Quit does nothing until it finally quits evolution about 10 minutes later. Happened twice to me now.
Do you have networking issues with any other apps over the course of a suspend/resume? Web browser, IRC, or anything like that? Evolution isn't aware of suspend/resume. Might be that it's still trying to use an open socket from prior to the suspend. How do other apps handle this?
Firefox & Pidgin seems to handle this fine. But you may be right with the open socket but I guess it should be enough to handle the NetworkManager dbus signals correctly without the need to take care of suspend itself.
> In addition choosing File->Quit does nothing until it finally quits > evolution about 10 minutes later. Disconnect from the network in nm-applet and reconnect fixes this for me, but it's annoying.
Created attachment 126836 [details] Backtrace of hung Evolution after suspend & resume
Comment on attachment 126836 [details] Backtrace of hung Evolution after suspend & resume I encounter this bug nearly every time I suspend & resume (even when on the same network).
This didn't happen anymore since at least GNOME 2.28. Maybe it got fixed with new IMAP code or with Matthew's kill-bonobo stuff. Feel free to close it if nobody objects.
*** Bug 670981 has been marked as a duplicate of this bug. ***
*** Bug 646801 has been marked as a duplicate of this bug. ***
*** Bug 650685 has been marked as a duplicate of this bug. ***
*** Bug 659873 has been marked as a duplicate of this bug. ***
*** Bug 671105 has been marked as a duplicate of this bug. ***
Milan, are you _sure_ all of those are dupes? I repeat again that the case me and several others were experiencing on one of the dupes certainly doesn't date back to 2008, and does not depend on changing wireless networks. Or wireless networks at all. This system is on an Ethernet connection. Every single time I suspend and resume, Evolution permanently loses network connectivity until it is restarted. This did not happen with Fedora 16, which restricts the timeframe to late 2011 onwards.
I am being referred here from Bug 670981. The behaviour described here does not exactly match the experience of the referring report, and while this bug dates from 2008, Bug 670981 relates only to versions > 3.2. I maintain that this is a new bug and the last known working version was 3.2.3 (with gnome 3.2).
FWIW this appears to work correctly with Evolution 3.5.1.
*** Bug 487898 has been marked as a duplicate of this bug. ***
*** Bug 555359 has been marked as a duplicate of this bug. ***
FWIW, with the 3.4.3 release that came in through my distro (F17) updates today, it now seems to work (I have not *thoroughly* tested though... others are welcome to confirm), compared to 3.4.2.
Well, it doesn't seem to get really better. I've tried this morning: * suspended the laptop without making evolution offline * resumed in another network * evolution is spinning there, not managing to refresh anything
The suspend/resume case does seem to be working in 3.4.3, I guess that's what J-F has. I've suspended/resumed twice since getting 3.4.3 and it's worked both times.
I'm not sure about simple suspend/resume case, but this is about network changes, and it doesn't work fine here.
I think this is related to nspr/nss, which is used for SSL connections in mailer part. I just tried to reproduce this with IMAP, which is connecting to my server, which is hidden under vpn. Going to suspend and then resume makes vpn connection drop, nonetheless, after several seconds (up to a minute), the connection timeouts and an error is reported to the user in UI. This is with: nspr-4.9-2 nss-3.13.4-3 I guess my vpn scenario covers Yves-Alexis' case too, because when I run vpnc again, then Evolution will connect to the server and work like nothing happened again.
(In reply to comment #21) > I guess my vpn scenario covers Yves-Alexis' case too, because when I run vpnc > again, then Evolution will connect to the server and work like nothing happened > again. Oops, nope, I was too quick in speaking. I am able to partially reproduce this. After resume, if I click Send/Receive, then it is stuck. I can cancel it by Cancel button or Cancel all (it's necessary to cancel it). Then the next Send/Receive works as expected. I'll check how to set timeout on the connection, to not wait too long. 60 seconds might be fine, I believe.
Created attachment 219014 [details] [review] eds patch for evolution-data-server; With this patch the connect, read and write operations on TCP streams use one minute timeout, thus if connection gets suddenly lost, the request timeouts. Previously used functions PR_Read/PR_Write didn't allow timeout setting, though here is obvious that the connection is done over network, not locally.
Created commit 86160aa in eds master (3.5.5+) Created commit a511ec3 in eds gnome-3-4 (3.4.4+)
*** Bug 679319 has been marked as a duplicate of this bug. ***
*** Bug 557078 has been marked as a duplicate of this bug. ***