Bug 1541651

Thanks for a bug report. I tried to reproduce this, but no luck, it works fine for me, I do not receive any "Repository offline" errors after rebooting the machine into GNOME and running evolution manually (either from Activities or from a terminal).

These "Repository offline" usually mean that the respective part failed to connect to the server. My machine has the connection to the server right after login, thus it doesn't claim it. You mentioned that this also repeats minutes later, which is quite odd, especially when your connection to the Exchange server did not change.

I suppose you use evolution-ews, not evolution-mapi, right?

I guess from your escription that there happes something with the online state detection when you run under GNOME for some reason. You can change how Evolution detects connection to the server in Edit->Preferences->Network Preferences, which may or may not help.

(In reply to Milan Crha from comment #1)
> I suppose you use evolution-ews, not evolution-mapi, right?

Oh, you wrote it already, it's evolution-ews. I'm sorry for a silly overlook.

Thanks for trying to reproduce the problem.  I did double check that I am using ews--when I look in Edit->Preferences->Mail Accounts I see that my main e-mail account has the type "ews".

Does the evolution-ews component talk to some GNOME desktop component that doesn't exist under other desktop environments?  For example, something that seems different is that there is some GNOME tool that asks for me to login to my e-mail account before I even start up Evolution manually (gnome-calendar??).  I am assuming it is there to check if I have new e-mail on the server and see if I have any appointments.  Does that component somehow interact with Evolution directly?  Could they contend with each other somehow?

I did see the Edit->Preferences->Network Preferences settings.  For me, it was on the "Default" setting for "Method to detect online state".  To see if it would make a difference, I changed the setting to "networkmanager" (which might be the same as "Default"), but it didn't make a difference.

When I am under GNOME and am running Evolution, another symptom or indicator that there are connection problems is that I can select any of the views other than "Mail" (e.g., "Contacts", "Calendar", "Tasks", "Memos") and the connection icons to the right of my calendar, contacts, task, and memo resources on the Exchange server all show they are offline with an icons that kind of look like:

 -->
<-- x

I can right click on individual resources on the Exchange server and select "Refresh".  That seems to force Evolution to establish a connection to that resource and that works at least some (most?) of the time.

When I am using Evolution under Plasma or Xfce, the icons show there is a connection with no problems:

 -->
<--

I just tried a different experiment that might be enlightening:

1. After a clean boot, I logged into the system with GNOME, ran Evolution, and had the problems I am reporting.  If I log out and then log in with Plasma, I see similar problems with Evolution that I saw under GNOME (which I don't normally see).  

2. After that, I rebooted the machine and logged in with Plasma first instead and Evolution isn't having the connection problems--everything comes up quickly and I can access all of my resources on Exchange with no problems and no need to "Refresh" or "Reconnect".

I have tried the two scenarios above a few times and it seems like the behavior for both 1 and 2 are reproducible, which suggests that maybe there is something that the GNOME desktop environment is starting that may be interfering.

Any suggestions on what to try next to better understand the problem?  Thanks!

While I don't think it is relevant, all of these experiments and experiences have been connecting to the corporate Exchange server when behind the corporate firewall.  Further, we do have a corporate proxy server as well.  While I don't think this is the cause of the issue, I thought it was worth mentioning.  

To be clear, my Fedora machine and the Exchange server are on the same side of both the firewall and proxy, so they shouldn't be a factor here.

Right, while reading about the symptoms at comment #3 I begun to think that maybe you've set a system proxy in GNOME, but not in other desktop environments. Could you verify that in GNOME settings, please? Another way would be to create a new user on the machine, reboot (I would not do that, but as reboot makes a difference here, better to do it) and login as the new user, configure there the EWS account and watch how it'll behave.

Bug #1302658 comment #4 contains a little test program, which verifies accessibility of certain addresses and reacts to network changes. You can modify it to the address of your EWS account and watch the result there. Search for "www.gnome.org" and change it to your EWS server host name. Also change the port from 80 to 443.

Here are a couple of results.

First, both the Plasma and GNOME are using the same proxy setup--an automatic proxy script provided by the organization.  So, that looks to be the same.

The first time I ran the modified test program under GNOME, it didn't successfully connect to the mail server over the HTTPS port (443) (note I have replaced the actual name of the mail server with <mailserver> below) : 

[2018-02-07T15:15:42.610233Z] network_available_cb: available:1
[2018-02-07T15:15:42.889599Z] network_available_cb: <mailserver>:443 reachable:0 (GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying)

I ran it a few more times, though, and it successfully connected:

[2018-02-07T15:18:26.992940Z] network_available_cb: available:1
[2018-02-07T15:18:27.475309Z] network_available_cb: <mailserver>:443 reachable:1 

Likewise, if I run the original version which tries to talk to www.gnome.org, it looks like it is having problems:

[2018-02-07T15:19:57.755739Z] network_available_cb: available:1
[2018-02-07T15:19:58.027060Z] network_available_cb: www.gnome.org:80 reachable:0 (GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying)

If I manually setup the proxy via the HTTP_PROXY environment variable before running, the original version of "test_nm" succeeds:

[2018-02-07T15:25:46.068650Z] network_available_cb: available:1
[2018-02-07T15:25:47.637755Z] network_available_cb: www.gnome.org:80 reachable:1

I have noticed that there are several GNOME programs that seem to have problems with the proxy even though it is set the via the network settings.  Firefox and other programs, though, seem to be happy.  I'll try a few more things out and let you know.

It turns out that test_nm under GNOME says that www.gnome.org:80 is reachable on the second try onward.  It might not have been related to setting the environment variable after all.

The other thought I had was that maybe the reason I see the reconnect issues is that Evolution has some timeout for its connection to EWS and what I am seeing are its attempts to re-establish/refresh the connection.

Also, even if test-nm (that talks to www.gnome.org:80) is successful, if run the test-nm-mail version right afterward, test-nm-mail may or may not fail on its connection to the mail server.  If I run test-nm-mail repeatedly it has problems frequently (3 out of 12 times).

I will try to set the proxy manually to see if that makes a difference.

In the GNOME Network Settings, I moved from the Automatic Proxy script approach to Manual Proxy configuration (manually defining the HTTP, HTTPS, SOCKS, FTP proxies).  That seemed to make a big difference in reliability.  Now when I run the test-nm and test-nm-mail test programs, they reliably connect to the two servers--no errors.  I does seem like Evolution in much happier as well.

Likewise, when I am in Plasma using the Automatic Proxy script approach (as opposed to manually setting the proxy by protocol), test-nm and test-nm-mail are reliable - no failures.

So, it does look like the problem that I have been having is related to the proxy configuration in GNOME.  The fact that connections to things are intermittent in GNOME with the Automatic configuration script approach to proxy settings is a bit strange.  I would have expecting things to either work or not work given the automatic proxy configuration.  I wonder if there is some refresh of the automatic proxy configuration that is failing behind the scenes (just a wild guess).  Otherwise, it is weird that things are intermittent.

(In reply to psg_nm from comment #6)
> reachable:0 (GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message
> recipient disconnected from message bus without replying)

This error sometimes means that something crashed or closed unexpectedly. I've no idea what it tries to talk to, but maybe when you run:

   $ dbus-monitor &>log.txt

and then repeat this error, then it might be eventually shown in the log.txt as well, where you might, somehow, find out what D-Bus service was failing.

Being it a real crash, it might be caught by ABRT, if you have it enabled in the system. Maybe the system journal will show something.

Created attachment 1393508 [details]
journalctl clip capturing glib-pacrunner crash

Here is a capture of "journalctl -r" which illustrates that glib-pacrunner has crashed.  I ran the following sequence:

dbus-monitor &> dbus-monitor.log
./test-nm (successful)
dbus-monitor &> dbus-monitor2.log
./test-nm (caused the crash)

The "journalctl -r" snippet that I provided may have a little from when I ran ./test-nm successfully, just so you know.

As noted above, it is clearly "glib-pacrunner" that is crashing.

I have run all day with the manual proxy settings under GNOME and Evolution has run very well (much like I was seeing under Plasma and Xfce).

Let me know what other information I can provide.

Thanks for the update. I'm pasting below the crashing thread for easier searching.
What is your installed version of mozjs38 and libproxy-mozjs packages, please
(rpm -q mozjs38 libproxy-mozjs)? I do not have the later installed at all.

I'm moving this bug report to libproxy for further investigation.

Stack trace of thread 4194:
#0  0x00007fa751f54510 _Z21JS_AbortIfWrongThreadP9JSRuntime (libmozjs-38.so)
#1  0x00007fa751f65512 _ZN2js14DestroyContextEP9JSContextNS_18DestroyContextModeE (libmozjs-38.so)
#2  0x00007fa75218fe4f _ZN15mozjs_pacrunnerD0Ev (pacrunner_mozjs.so)
#3  0x00007fa754ea5ca8 _ZN8libproxy19pacrunner_extension3getENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_3urlE (libproxy.so.1)
#4  0x00007fa754eaa37a _ZN8libproxy13proxy_factory7run_pacERNS_3urlERKS1_RSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISB_EE (libproxy.so.1)
#5  0x00007fa754eab202 _ZN8libproxy13proxy_factory11get_proxiesENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE (libproxy.so.1)
#6  0x00007fa754eab652 px_proxy_factory_get_proxies (libproxy.so.1)
#7  0x000055788f0c3bad get_libproxy_proxies (glib-pacrunner)
#8  0x00007fa7556aee16 g_task_thread_pool_thread (libgio-2.0.so.0)
#9  0x00007fa75512ee50 g_thread_pool_thread_proxy (libglib-2.0.so.0)
#10 0x00007fa75512e486 g_thread_proxy (libglib-2.0.so.0)
#11 0x00007fa75402061b start_thread (libpthread.so.0)
#12 0x00007fa754bd298f __clone (libc.so.6)

Here they are:

$ rpm -q mozjs38 libproxy-mozjs 
mozjs38-38.8.0-6.fc27.x86_64
libproxy-mozjs-0.4.15-4.fc27.x86_64

Next time, please include a proper stacktrace taken with gdb: consider it mandatory for all crash reports. Thanks.

*** This bug has been marked as a duplicate of bug 1459779 ***