GNOME Bugzilla – Bug 650685
Evolution gets confused when network is disconnected and reconnected
Last modified: 2012-05-18 15:00:52 UTC
I sometimes experience this - suspend the laptop - when I resume, Evolution will correctly be in "offline" mode, and present an infobar saying network is down - after a little while, wifi network reconnects - Evolution won't see that, and will be stuck in "offline" mode - quit Evolution - as soon as I press the quit button, the network connection presence is detected, and the app tries to fetch mail for all my folders in all my accounts, which takes a long time (or forever if e.g. I have a VPN-ed mail account and my VPN connection is not on, but this is a separate bug), so it won't effectively quit. This is with 3.0.1 on Fedora 15.
If you run Evolution from a terminal, you should see some messages printed when network availablity changes. For example: evolution-shell-Message: Network disconnected. Forced offline. evolution-shell-Message: Connection established. Going online. What terminal messages do you see after a suspend/resume cycle? Not sure why it would not see the wifi reconnect, unless it's not receiving the D-Bus signal from NetworkManager for some reason.
Similar downstream bug report also with 3.0.1: https://bugzilla.redhat.com/show_bug.cgi?id=706413 Evolution disconnects from IMAP when network is lost. It doesn't reconnect afterwards. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Open evolution with an IMAP+ account 2. Disconnect from network (e.g. suspend) 3. Connect back 4. Click send & recieve 5. Toggle online 6. Click send & recieve Actual results: after 2) Evolution loses connection after 3) Evolution doesn't reconnect after 4) Evolution shows an error and switches to offline mode (it's online now!) after 5) Evolution switches back online but doesn't recieve messages after 6) Evolution finally downloads the mail (but it's not really fast) Expected results: after 2) Evolution should switch itself offline after 3) Evolution should switch itself online, reconnect to IMAP, and recieve messages steps 4, 5 and 6 should not be needed at all Additional info: Evolution doesn't recieve mail immediately, does it try to use IDLE?
FWIW, I'm also seeing this in Fedora 15, only that this is on a desktop computer with a wired connection, so there's almost no delay in reestablishing the network connection on resuming from suspend. Evolution stays stuck in offline mode until I click the icon to force it online in the lower left corner.
I made some changes in this area yesterday that might help. I noticed when our session bus connection drops, we wait 3 seconds before attempting to reconnect, and if that fails we retry every 3 seconds thereafter until we're connected again. I suppose it's possible that NetworkManager may be broadcasting status signals during that initial 3 second delay. I changed the logic to make the initial reconnect attempt immediately. http://git.gnome.org/browse/evolution/commit/?id=42b4f85ec5263c1715f5dfd01d0f3c289b8a9c68 Once we're reconnected, we query NetworkManager for the current connection status. But then there was some old-looking logic in Evo that didn't update the "network-available" flag properly, so I fixed that too. http://git.gnome.org/browse/evolution/commit/?id=e868dd4bfdeb80090c42a8188ebadbc0d75ca308 So basically we only reconnect if we catch NetworkManager's D-Bus signal. The network status queries are ineffective. Assuming the session bus connection drops out just prior to a suspend (or perhaps just after resuming... not really sure how that works), it might be that we were racing to reconnect in time to catch NetworkManager's status signal. I'm totally speculating here. But git master seems to now handle suspends better for me.
I learned from a collague that D-Bus connections survive a suspend and resume without dropping, so my first commit is probably not relevant to this bug. My second commit may still be, or it may be some NM 0.9 vs NM 0.8 thing.
*** Bug 656195 has been marked as a duplicate of this bug. ***
bug 658893 might be related
There is another problem with the way the NM integration works. 1. You are online, say you are in the office. 2. Suspend your laptop and leave. 3. On the train you start working again. 4. You want to go online over 3G, but you don't evolution to pick up mail because the 3G connection is unreliable. So how can you prevent evolution not fetch mail as soon as there is a connection?
(In reply to comment #8) > There is another problem with the way the NM integration works. > > 1. You are online, say you are in the office. > 2. Suspend your laptop and leave. > 3. On the train you start working again. > 4. You want to go online over 3G, but you don't evolution to pick up mail > because the 3G connection is unreliable. > > So how can you prevent evolution not fetch mail as soon as there is a > connection? I don't think you should prevent it fetching mail in this configuration, as long as Evolution itself is not too verbose about its failed attempts to retrieve mail and fetching does not block/slow down other operations such as trying to compose a message. Anyway, as for the original bug, I still see delays in Evolution picking up connection changes from NM with 3.2.1.
(In reply to comment #9) > I don't think you should prevent it fetching mail in this configuration, as > long as Evolution itself is not too verbose about its failed attempts to > retrieve mail and fetching does not block/slow down other operations such as > trying to compose a message. What happens if Evo tries to fetch mail over a flaky connection is this: 1. I have a lot of emails to fetch, say ~ 150 2. Connection breaks up before Evo finishes fetching all these mails. As this is tethering over my mobile and the wifi connection is still intact, evo doesn't recognize I am effectively offline and the connection to the server just times out before the fetched mails are expunged. 3. Next time I fetch mail I get all 150 mails again. I now have a lot of duplicates filtered into many different folders. Long story short: There are good reasons to manually 'overwrite' the automatic online/offline mode Evo gets from NM and this is not possible with the current implementation.
(In reply to comment #10) > What happens if Evo tries to fetch mail over a flaky connection is this: > 1. I have a lot of emails to fetch, say ~ 150 > 2. Connection breaks up before Evo finishes fetching all these mails. As this > is tethering over my mobile and the wifi connection is still intact, evo > doesn't recognize I am effectively offline and the connection to the server > just times out before the fetched mails are expunged. What do you mean? Is the connection actually down, or just of poor quality? > 3. Next time I fetch mail I get all 150 mails again. I now have a lot of > duplicates filtered into many different folders. This is a completely different problem: if Evo downloaded a mail, it should be able to remember that and to skip/remove it next time. Please file another bug. (And if you can, use IMAP, you won't get these issues.) > Long story short: There are good reasons to manually 'overwrite' the automatic > online/offline mode Evo gets from NM and this is not possible with the current > implementation. No, I think this bug should just be fixed. No need to work around bugs by forcing Evo online/offline.
“No need to work around bugs by forcing Evo online/offline.” This is simply not true, for two reasons: 1) Evolution breaks in so many cases that it's not possible to fix all these weird behaviors in reasonable time. A workaround that covers all of them is soft of a blessing for the unfortunate user. 2) Evolution forces user to use the online/offline switch manually anyway, as it doesn't respond to NM connect well. At least the version in Fedora, which is pretty new. An experimental piece of software like Evolution should allow user to do as many workarounds as possible to overcome the omnipresent misfeatures.
(In reply to comment #12) > “No need to work around bugs by > forcing Evo online/offline.” > > This is simply not true, for two reasons: > > 1) Evolution breaks in so many cases that it's not possible to fix all these > weird behaviors in reasonable time. A workaround that covers all of them is > soft of a blessing for the unfortunate user. Pointers? There are many little bugs in Evo, but I've never had to go online/offline to work around them. > 2) Evolution forces user to use the online/offline switch manually anyway, as > it doesn't respond to NM connect well. At least the version in Fedora, which is > pretty new. Which Fedora release? The present bug *is* about fixing this, and correctly following NM's status is obviously the thing to do. > An experimental piece of software like Evolution should allow user to do as > many workarounds as possible to overcome the omnipresent misfeatures. Evo is not "experimental". It's been around for years, and works reasonably well in most cases. Anyway, this report is not the place to discuss whether workarounds are needed in general or not. If you have precise bugs, file them as new reports. Cosimo, since you seem to be the only person who tested 3.2, do you think the report should stay open? Is the update delay reasonable?
*** Bug 658893 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > What do you mean? Is the connection actually down, or just of poor quality? The 3G connection of the mobile to the internet is down, however the wifi from the laptop to the mobile is up. > This is a completely different problem: if Evo downloaded a mail, it should be > able to remember that and to skip/remove it next time. Please file another bug. I already filed bug 658365 (just updated), now I filed bug 663693 for the problem with expunging mails. > (And if you can, use IMAP, you won't get these issues.) Great idea with a GMail account with 400.000 mails in there. ;) > No, I think this bug should just be fixed. No need to work around bugs by > forcing Evo online/offline. As you can see with the 3G example there will always be situations that NM cannot catch. There should be a way to manually set offline mode - even while offline due to NM.
(In reply to comment #15) > The 3G connection of the mobile to the internet is down, however the wifi from > the laptop to the mobile is up. That's a bug in NM then. I remember reading discussions about implementing API to allow apps to check whether they have Internet access or not. This is also useful when using public WiFi which requires you to authenticate via a web page before accessing the net.
(In reply to comment #15) > As you can see with the 3G example there will always be situations that NM > cannot catch. There should be a way to manually set offline mode - even while > offline due to NM. Just wondering, would the disabling of NetworkManager support do the trick, letting you set evolution online/offline on your own? Listening to NW line status in your case (and particularly in most cases where vpn is involved) doesn't do the right thing, thus avoiding automatic checking and to it manually seems like the right way, at least for now. Fedora have evolution-NetworkManager package, which has only this module, or you can just remove /usr/lib64/evolution/3.2/modules/libevolution-module-network-manager.so and all the automatic checking for online/offline will be a history. (The path is relevant for my F16 64bit installation).
(In reply to comment #16) > (In reply to comment #15) > > The 3G connection of the mobile to the internet is down, however the wifi from > > the laptop to the mobile is up. > That's a bug in NM then. I remember reading discussions about implementing API > to allow apps to check whether they have Internet access or not. This is also > useful when using public WiFi which requires you to authenticate via a web page > before accessing the net. This seems to be on the roadmap for NM 9.4: "We’ll probably have connectivity detection as well." http://blogs.gnome.org/dcbw/2011/11/10/blue-sky-white-sand-and-networkmanager-0-9-2/ And the patch is at: http://mail.gnome.org/archives/networkmanager-list/2011-October/msg00225.html So it looks like most of your problems will eventually go away for 3.4!
Apparently no one has tried "evolution --force-online"...
Well, that wont help you if evolution is already running. And I cannot close it because then I'd have to save all my drafts and this will hit bug 654115 again.
I have a confusing issue with Evolution in Gnome 3.4 now, in 4.2 it worked well. After reconnecting to the network, Evolution says on the shell that it is online[1], but it stays offline (showing the 'Evolution will go online when connection is back' message). When I want to close it, it's hanging saving the current IMAP-Folder until it gets killed. I have this issue on two ArchLinux systems. Evolution 3.4.2 networkmanager 0.9.4 [1] evolution-shell-Message: Network disconnected. Forced offline. evolution-shell-Message: Connection established. Going online.
I have exactly the same issue, and I reported it on bug 667875 (see my last comment, and comments from Milan Crha).
*** This bug has been marked as a duplicate of bug 551788 ***