GNOME Bugzilla – Bug 722280
Reconnecting after a connection lost doesn't work
Last modified: 2018-12-12 14:59:45 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1024314 Paraphrasing the downstream bug report (because I noticed it with 3.11.x too): When there is a connection lost (either VPN or any general), and then the connection is restored again, then evolution doesn't reconnect mail accounts properly, it sits in a state where status bar keeps shown activities like "Pinging IMAP server" and similar, while simply closing evolution and starting it again makes the connection instantly. Thus there is some issue with connection availability detection (maybe the connection status caching on the GLib side strikes here?).
More info from another similar bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1037977 I have an ews exchange account configured in evolution, which works fine. But if I put my laptop to sleep, this account doesn't work after resume from suspend. There is no new email notification, and if I click and Send/Receive button, the progress bar of the exchange account doesn't move, stuck on a "Reconnect to 'exchange'" message. If I restart evolution, this account goes back to life.
This should work better in 3.12, where each email account now manages its own online/offline state with the help of GNetworkMonitor.
Can we get a fix in 3.10 of some sort? It's really annoying as I can never keep evolution open and have to keep shutting it down every time I need to reconnect whether it be a wifi connection or vpn
I agree with Peter Robinson, we are on 3.10.3 in repos for Fedora 20 (latest version). There is a pretty long wait before we see 3.12.x in Fedora I think. My team all uses evolution to connect to our exchange ews and we are on-call a lot which requires VPN access from anywhere outside the office. The minute we connect to VPN we lose evolution. We have to kill evolution and re-open it, this is not a great solution because often we forget and start working on issues and by the time we switch back to evolution to email the NOC or give updates we find evolution spinning away with tons of tasks like refreshing folders or connecting to server now queued up in the tray. The only way to stop it is to kill -9 all evolution processes at this point. Very very aggravating.
(In reply to comment #2) > This should work better in 3.12, where each email account now manages its own > online/offline state with the help of GNetworkMonitor. As I noted in comment #0, I see the same behaviour in 3.11.x, currently git master after 3.11.4, thus the 3.12 doesn't have it fixed or improved yet.
(In reply to comment #4) > I agree with Peter Robinson, we are on 3.10.3 in repos for Fedora 20 (latest > version). There is a pretty long wait before we see 3.12.x in Fedora I think. Fedora 20 won't be released until August (or there abouts). I'll move to F-21 long before that, normally between alpha/beta, as I need a stable device for $dayjob and it's bloody annoying so it would be very nice to see a fix in 3.10.x
I have the same problem, also very annoyed. Work from home over an unreliable VPN so restarting evo a lot. I really don't want to go back to firefox, their calendar is horrible (or was last time I used it), but this is fast approaching a showstopper for me.
I'm still seeing this issue with Fedora's evolution-ews-3.12.9-1.fc21.x86_64. Two changes from the versions in Fedora 20: First, switching to and from VPN no longer seems to disconnect Evolution from the exchange server, but suspending and resuming on another network still does. Also, it was the case before that issuing 'evolution --force-shutdown" cleanly shut down Evo so that it could be restarted, with the message "process exited normally" or something similar. Instead, now I get the following message: $ evolution --force-shutdown ** (evolution:7197): WARNING **: Shell not finalized on exit No response from Evolution -- killing the process Repeated forces used to eventually result in a clean shutdown, but now they have the same result as above, except that the process number changes. The ps command shows running evolution-calendar-factory and evolution-source-registry, but no running evolution process. Starting evolution again does seem to work fine, however.
There had been done several changes in the code related to this bug, while I believe they fixed the bug together, thus I'm closing this. Feel free to reopen or comment in case you can reproduce with the current 3.30.x stable series.