GNOME Bugzilla – Bug 735308
[abrt] gnome-shell: calendar_sources_init(): gnome-shell-calendar-server killed by SIGTRAP
Last modified: 2014-12-15 01:18:57 UTC
Downstream abrt bug: https://bugzilla.redhat.com/show_bug.cgi?id=1123674 More info available there. Version-Release number of selected component: gnome-shell-3.13.4-1.fc21 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/libexec/gnome-shell-calendar-server crash_function: calendar_sources_init executable: /usr/libexec/gnome-shell-calendar-server kernel: 3.16.0-0.rc6.git2.1.fc21.x86_64 runlevel: unknown type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (9 frames) #2 calendar_sources_init #3 g_type_create_instance at /lib64/libgobject-2.0.so.0 #4 g_object_new_internal at /lib64/libgobject-2.0.so.0 #7 calendar_sources_get #8 on_bus_acquired #9 connection_get_cb at /lib64/libgio-2.0.so.0 #10 g_simple_async_result_complete at /lib64/libgio-2.0.so.0 #11 complete_in_idle_cb at /lib64/libgio-2.0.so.0 #13 g_main_context_iterate.isra at /lib64/libglib-2.0.so.0
From the downstream bug: ---- [System Logs]: Jul 27 17:50:01 localhost.localdomain abrt-hook-ccpp[2025]: Saved core dump of pid 2017 (/usr/libexec/gnome-shell-calendar-server) to /var/tmp/abrt/ccpp-2014-07-27-17:50:01-2017 (36614144 bytes) [User Logs]: Jul 27 17:49:48 localhost.localdomain org.gnome.Shell.CalendarServer[657]: gnome-shell-calendar-server[901]: Lost (or failed to acquire) the name org.gnome.Shell.CalendarServer - exiting Jul 27 17:50:01 localhost.localdomain org.gnome.Shell.CalendarServer[1878]: (gnome-shell-calendar-server:2017): ShellCalendarServer-ERROR **: calendar_sources_init: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources3: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program org.gnome.evolution.dataserver.Sources3: Success ----- Do you have evolution-data-server installed?
Yes. I just installed the system from alpha-TC3: [asinha@localhost ~]$ rpm -qa \*evolution\* evolution-data-server-debuginfo-3.12.5-2.fc21.x86_64 evolution-data-server-3.12.5-2.fc21.x86_64 evolution-ews-3.12.5-2.fc21.x86_64 evolution-help-3.12.5-2.fc21.noarch evolution-3.12.5-2.fc21.x86_64 [asinha@localhost ~]$
Still seeing this: gnome-shell-3.14.0-2.fc21.x86_64 After this, when the shell comes up, the calendars aren't shown in the top panel - neither are the "open calendar" option. If I restart the shell, they show up. Probably something to do with e-d-s.
Seems like it happens on each login. Not sure how to collect more info. Any hints?
After some investigation, it seems to be caused by hitting the 25 seconds timeout on starting evolution-source-registry. Relevant logs: Dec 10 10:51:14 giovanni-laptop org.gnome.Shell.CalendarServer[1439]: (gnome-shell-calendar-server:1568): ShellCalendarServer-ERROR **: calendar_sources_init: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources3: Timeout was reached Dec 10 10:51:49 giovanni-laptop gnome-session[1431]: Gjs-Message: JS LOG: Error loading calendars: Error calling StartServiceByName for org.gnome.Shell.CalendarServer: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process org.gnome.Shell.CalendarServer received signal 5 Dec 10 10:51:21 giovanni-laptop gnome-session[1431]: Error calling StartServiceByName for org.gnome.evolution.dataserver.Sources3: Timeout was reached Dec 10 10:52:01 giovanni-laptop org.gnome.evolution.dataserver.Sources3[1439]: Bus name 'org.gnome.evolution.dataserver.Sources3' acquired. evolution-source-registry is running fine, but you can see it takes 47 seconds to start (I don't know who is trying to start e-s-r at 10:51:21, maybe some other app or service?) Now, ideally e-s-r would not take this long before acquiring the bus name. Looking at the code, it seems that before acquiring the bus name, it tries to migrate the old (pre 3.12? 3.10?) configuration, which can be disabled, but it also tries to synchronously load all sources from the disk. A simple test on my system shows that it takes 12 seconds (10 if I disable migration) to load, with no other concurrent IO but with cold caches. It is clear that hitting 25 is possible, in a condition such as login where there is a lot of other concurrent IO happening. OTOH, we cannot increase the timeout: g_dbus_proxy_new (eventually called by e_source_registry_new()) hardcodes using the default timeout for its StartServiceByName call, and g_dbus_connection_call() hardcodes 25 seconds as the default. We could change the timeout to be higher for all gdbus programs, or for all g_dbus_proxy_new() calls, on the grounds that starting a service can reasonably require more than 25 seconds if the service has to load itself, its configuration and its data. I'm not sure it's a good idea in general. OTOH, a simple workaround is to StartServiceByName manually before using the eds library call, with a higher timeout.
Created attachment 292502 [details] [review] calendar-server: activate evolution-source-registry manually at startup g_dbus_proxy_new() (and library calls that wrap it) has an hardcoded timeout of 25 seconds, which is insufficient for starting up e-s-r in certain setups. Avoid a timeout error by starting the service manually with a longer timeout before hand. Also demote the error to a warning + exit failure instead of a crash, to avoid triggering abrt reports.
Created attachment 292503 [details] [review] Calendar: ignore timeouts starting the calendar-server In certain cases the timeout for starting the calendar helper can be reached but the calendar helper still loads fine. If so, just ignore the timeout and wait until we get a notification from dbus of the successful start.
Review of attachment 292502 [details] [review]: While this is a hack its better then what we have now.
Review of attachment 292503 [details] [review]: OK.
Pushed to master and gnome-3-14 Attachment 292502 [details] pushed as b21f5c5 - calendar-server: activate evolution-source-registry manually at startup Attachment 292503 [details] pushed as 0592ade - Calendar: ignore timeouts starting the calendar-server