GNOME Bugzilla – Bug 646801
Send/Receive hangs after change network connection
Last modified: 2012-05-18 16:54:24 UTC
If I change network connection (e.g. from wireless to wired or viceversa) while evolution is running, and then I check for new mail, the "Send/receive" window hangs. Cancelling does not work, the only way out is restarting evo. The automatic mail checking also stops working. This issue disappear if I change back the connection using the same which was active when evo was started. I'm using evolution 3.0 for archlinux, the building options are: ./configure --prefix=/usr --sysconfdir=/etc \ --localstatedir=/var \ --libexecdir=/usr/lib \ --disable-scrollkeeper \ --enable-nss=yes \ --with-openldap=yes \ --enable-smime=yes \ --with-krb5=/usr \ --disable-image-inline
As a workaround, switching to offline mode (skip syncing) then back to online mode is usually enough to force the network connections to reset.
(In reply to comment #1) > As a workaround, switching to offline mode (skip syncing) then back to online > mode is usually enough to force the network connections to reset. Ok the workaround does the job, thanks! But shouldn't Evolution be synchronized with NetworkManager? Could it depend on how the distribution packages Evo and N-M ?
It already does listen to NetworkManager and broadcasts network connectivity changes within the app, but some of the deeper parts of Evolution still misbehave and don't pay attention like they should.
Just a +1 on this, still happening with 3.1.4, it's kinda annoying.
This is the most annoying evolution bug I've experienced ever. Basically it means that I need to close it before suspending the laptop or even before switching from the wireless to the wired network. Switching to offline mode doesn't solve it (I know it used to, but not anymore with 3.2).
Additional information: when evolution is stuck after swiching network connections, closing it does nothing. The only way out is: [claudio@localhost ~]$ evolution --force-shutdown No response from Evolution -- killing the process
It also happens with 3.2.1 on Ubuntu. When something happens with the network like my IPv6 tunnel going down then Evolution hangs and the only way to stop is to use --force-shutdown. This seems to happen when: - My IPv6 connectivity breaks (server is reachable via IPv4) - Switching between networks - Suspend/Resume I'm using IMAP/S.
I'm having the Claudio case of this recently on F17 - if you suspend with Evo running, when you resume, it'll never be able to retrieve anything from the server until you kill it (with killev) and restart it.
This is with evolution-3.3.2-1.fc17.x86_64 , so the 'version' could be updated, I think.
Any chance of a fix for this? It's still going on in current Rawhide, evolution-3.3.4-1.fc17.x86_64 . It's a pretty annoying bug if you suspend regularly.
Still broken, and we're nearly at GNOME 3.4! Come on, guys, isn't this a bit too big of a bug to have in a stable release?
It seemed like Matthew was unaware of this when chatting about it on IRC, so I'll make it more explicit: my comment #8 implies that up until shortly before I made that post, and to the present day on F16, this works fine. It has not always been the case. I can happily suspend and resume my F16-running laptop as much as I like, and Evo handles it fine. I cannot do the same with my F17-running desktop.
Same problem here if my VPN connection dies, evolution just goes into lala land. They only way I can recover is to killall -9 evolution. This is a major, major bug in a released product.
yeah, VPN connection dying (as they usually do, after a while) is another annoying case of this. I'm getting to the point where I'm thinking about hacking up a pre-suspend hook to kill Evo and a post-suspend hook to run it again. That's not a point I really ought to be at. :/
Interesting news: this seems to have just recently broken in F16 too. I'm going to experiment with reverting recent NM and Evo updates to try and pinpoint what breaks it.
I think this is that close to bug #551788 that I can safely mark this as a duplicate of it. *** This bug has been marked as a duplicate of bug 551788 ***
Oh, update to #15, that never happened again. 16 is back to working fine. Still only 17 is broken.