IMAP? POP? Both server types?

All my servers are IMAP.

Same here with evolution 3.10.2 and 3.10.3 using three diffrent imap accounts.

I have a similar problem, it appears everytime NetworkManager changes the connection (wakeup from suspend, dis-/connecting from/to VPN, switching between LAN/WLAN).

Evolution hangs when polling the IMAP servers (POP works normally), and so I mostly end up with an "evolution --force-shutdown". Cancelling the tasks in evolution doesn't work either.

I have seen a few reports about this issue now (e.g. in OpenSUSE [1])


[1] https://bugzilla.novell.com/show_bug.cgi?id=607833

This should be fixed in 3.12.

I'm still seeing this issue in 3.12.1 on Arch Linux.

*** Bug 726102 has been marked as a duplicate of this bug. ***

I can confirm the bug’s still present in 3.12.1.

There had been done few more fixes during the time, up to the 3.12.11 or the current stable 3.16.0, but I'm afraid there are still some corner cases when this doesn't work as expected.

With 3.16.3 today I got error infobars upon resume that said:

  Failed to connect account "GMail".
  The reported error was "You must work online to finish ths operation".

...for every single imap account I have.

Evolution didn't realize I was online until I clicked a folder inside each imap account to trigger a refresh there. I didn't have to kill evo, it was not in a hung state downloading messages though, so is that the same issue?

Actually, I can reproduce this consistently just by suspending and resuming my laptop. See also bug #750963 for a different error (but related behavior) when turning the network off/on without suspending/resuming.

(In reply to Jean-François Fortin Tam from comment #11)
> Actually, I can reproduce this consistently just by suspending and resuming
> my laptop.

I guess it's unrelated to this bug report, also because I'm able to reproduce it too. I made some changes for 3.17.4+ (commit 049e186) and 3.16.4+ (commit 39c654e) to hide this error from UI, when it comes from the Send/Receive part.

For the initial issue, if anyone is able to reproduce this, could you provide a backtrace of the evolution in such state, with debuginfo packages installed for evolution-data-server and evolution itself, please? You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).

Also check what the UI says, what is shown in the status bar, when evolution gets into such state. Thanks in advance.

Created attachment 306182 [details]
screenshot

FWIW I tried the backtrace thing but I couldn't get it to trace, the output bt.txt by gdb only has: "ptrace: Operation not permitted."  And yet:

$ sudo setsebool deny_ptrace 0 
  setsebool:  SELinux is disabled.

$ grep "abled" /etc/selinux/config
  SELINUX=disabled

What the heck...

...anyway. I realize now that trace is not needed for the issue I was seeing in comment #10 - so, question regarding your fixes through commit 39c654e and commit 049e186: does it only hide the infobar/error, or does it make the thing fully realize it's online? Because there were not only the infobars, there were also the "connection status" icons (in the listview besides each account name in the sidebar) that made me believe that the backend thought it was still offline. So this was just a UI mismatch, it wasn't actually in offline mode?

(In reply to Jean-François Fortin Tam from comment #14)
> FWIW I tried the backtrace thing but I couldn't get it to trace, the output
> bt.txt by gdb only has: "ptrace: Operation not permitted."  And yet:

At least Fedora 22 requires:
   $ echo 0 >/proc/sys/kernel/yama/ptrace_scope
for a one-time setting (it's back at 1 after restart).

> commit 049e186: does it only hide the infobar/error, or does it make the
> thing fully realize it's online?

It ignores the errors, thus it simply hides the infobar. The thing is that the next attempt, possibly few seconds later, when the network is fully up, the provider is reconnected, and continues to work properly.

There were added some timeouts after network change, to give the underlying system time to fully initialize networking too, but it was done long before this change.

> It ignores the errors, thus it simply hides the infobar. The thing is that the next attempt, possibly few seconds later, when the network is fully up, the provider is reconnected, and continues to work properly.

> There were added some timeouts after network change, to give the underlying system time to fully initialize networking too, but it was done long before this change.

What I'm seeing in 3.16.4 is that it doesn't raise the erorr infobars anymore, but it does not ever realize the connection is back up until you switch folders/refresh manually... is that still considered the same issue? Should I open a new one?

The manual refresh isn't needed, the account is connected on demand, when there's invoke some activity, like the folder change, email read or the refresh, either manual or automatic. The icon beside the account name shows current connection status, not necessarily reachability of the destination server. The account is (auto-)connected only if the server is reachable.

As long as the evolution is not stuck on anything, it is a different issue. I think it's already filled, or at least something similar might be.

The initial problem (and description) seems long gone so I would say we can close this bug and follow-up in bug #779156 instead?

Thanks, I agree.