User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build Identifier: I have been having a number of problems with Evolution for the last few months while running under Fedora 27's Gnome (under both Wayland and X) and using my employer's Exchange server. Evolution repeatedly provides errors like: "Failed to connect calendar 'Calendar'" Repository offline (Reconnect Button) "Failed to connect memo list 'Notes'" Repository offline (Reconnect Button) "Failed to connect address book 'Contacts'" Repository offline (Reconnect Button) "Failed to connect 'an.email'" GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying (address changed for example) If I hit the "Reconnect" button many times for each data type that Evolution is trying to connect to on Exchange, they will eventually have a full connection temporarily. Minutes later, I will need to do the whole thing (or a subset of things) again. To the best of my knowledge, no data was ever lost due to this, but I finally got frustrated with Evolution and have been needing to file this bug. I have kept my machine up-to-date with DNF (now at 3.26.2 for many Gnome components). By chance, in trying to deal with the fact that my laptop has a HiDPI display, I have tried a few other desktop environments, namely, Plasma and XFCE. Oddly, I don't have those connection problems at all in those desktop environments--I only get connection warnings if, for example, I am off the network, as opposed to every several minutes. Considering that evolution is a Gnome Desktop application, I found this a bit surprising. As stated above, I am using Evolution to talk to my employer's Exchange server for email, calendaring, notes, todos, etc. These seem to work well when I am using Plasma and XFCE, but the connection problems are too frequent under Gnome to really be usable. Reproducible: Always Steps to Reproduce: 1. Login to Gnome 2. Setup Evolution to talk to Exchange server 3. Use Evolution for retrieving email, calendars, todos, notes, contacts, etc. Actual Results: As noted above, I get messages like: "Failed to connect calendar 'Calendar'" Repository offline (Reconnect Button) "Failed to connect memo list 'Notes'" Repository offline (Reconnect Button) "Failed to connect address book 'Contacts'" Repository offline (Reconnect Button) "Failed to connect 'an.email'" GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying (address changed for example) for effectively resource on the Exchange server and I have to hit the "Reconnect" buttons repeatedly to connect. They eventually go away for a little while, but often it takes multiple retries to connect to each resource. Further, I will get reconnect problems minutes later. Expected Results: No connection errors except for when there is no network or maybe the initial connection. As mentioned before, I don't see this problem at all under Plasma (KDE) or XFCE and Evolution works as expected. I have not tried using Evolution to talk to any other type of email or groupware server, so I don't know if this is exclusive to talking to Exchange servers or if it is a broader issue--my guess is that it has something to do with talking to Exchange servers otherwise a lot of people would be complaining.
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 ***