Description of problem: Process causes 18-25% CPU load. Also there is evolution-source-registry process with ~10% CPU load Version-Release number of selected component (if applicable): evolution-data-server-3.18.3-1.fc23.x86_64 How reproducible: Checking Steps to Reproduce: Starts from some moment Actual results: CPU load, laptop heats up without any useful load Expected results: Assume process should not consume CPU in background Additional info: top command snapshot PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2848 vader 20 0 3409508 99900 32304 S 18.6 1.7 19:37.76 /usr/libexec/evolution-calendar-factory-subprocess --factory caldav --bus-name o+ 2558 vader 20 0 1596492 47536 34160 S 10.3 0.8 10:47.06 /usr/libexec/evolution-source-registry [vader@tyche ~]$ cat /proc/2848/cmdline /usr/libexec/evolution-calendar-factory-subprocess--factorycaldav--bus-nameorg.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2681x2--own-path
I'm using Fedora Gnome desktop, Each time after system restart first user session logon causes this issue to be reproduced. Issue could be resolved after user performs logout and login again.
Thanks for a bug report. Hard to tell what the high CPU causes without getting a backtrace or something of it. The only thing visible is it's one (or more) of your CalDAV calendars. Could you install debuginfo package for the evolution-data-server (only that one, no need to install other debuginfo packages for its dependencies), then reproduce the issue and get backtraces of the two processes, when they'll use the high CPU, please? You can get the backtrace with a command like this: $ gdb --batch --ex "t a a bt" -pid=PID &>btPID.txt Where you'll replace the PID with a concrete process ID. 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). That may help to identify what the calendar, or the source registry, is doing. Thanks in advance.
I encountered similar issue. However as soon as i start gnome-calendar, evolution-data-center drops load to normal. (so maybe gnome-calendar is related) gnome-calender itself is also a resource hog, when on the foreground it consumes 20% cpu and causes xserver and gnome-shell to do the same...
Created attachment 1117335 [details] evolution-source-registry PID TTY STAT TIME COMMAND 2423 ? Sl 12:04 /usr/libexec/evolution-source-registry
Created attachment 1117336 [details] evolution-calendar-factory-subprocess PID TTY STAT TIME COMMAND 2725 ? Sl 21:30 /usr/libexec/evolution-calendar-factory-subprocess --factory caldav --bus-name org.gnome.evolution.dataserver.Subprocess.Ba
Hi Milan, Thank you for the follow-up, sorry for the late response Please find files attached, hope they will show who is the guilty=) Cpu utilization picture was like that: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2725 vader 20 0 2827976 99328 32288 S 70.9 1.7 17:54.99 evolution-calen 2423 vader 20 0 1568632 47588 33988 R 38.7 0.8 9:55.54 evolution-sourc By the way is there a way to install debuginfo package for the single package? I have failed with this, did not find any suitable keys to do this. I have used following command which installed about 6 Gigs for all dependencies $ sudo dnf debuginfo-install evolution-data-server
I get these in the log when it happens to me: org.gnome.evolution.dataserver.Calendar7[2527]: (evolution-calendar-factory-subprocess:3015): libsoup-WARNING **: SoupMessage 0x7f641000a2b0 stuck in infinite loop?
(In reply to Iaroslav Prokopenko from comment #4) > evolution-source-registry It shows all the threads idle, waiting for orders. It can by only a coincidence that it doesn't do anything at this moment. (In reply to Iaroslav Prokopenko from comment #5) > evolution-calendar-factory-subprocess This one shows many threads, some resolving server addresses, some connecting to the server. How many CalDAV calendars do you have configured, please? It looks like at least 12 from the backtrace. (In reply to Iaroslav Prokopenko from comment #6) > $ sudo dnf debuginfo-install evolution-data-server I use: $ dnf install evolution-data-server-debuginfo --enablerepo=*-debuginfo and I make sure the downloaded version is the same as the binary package version. Eventually download it from the koji server: http://koji.fedoraproject.org/koji/ where you can search for the package and pick the version you've installed, then download it and install it as: $ dnf install ./package.rpm eventually $ dnf update ./package.rpm (In reply to dac.override from comment #7) > I get these in the log when it happens to me: > > org.gnome.evolution.dataserver.Calendar7[2527]: > (evolution-calendar-factory-subprocess:3015): libsoup-WARNING **: > SoupMessage 0x7f641000a2b0 stuck in infinite loop? Right, it can be related. I didn't see it myself yet. I'm wondering how that can be reproduced.
It seems to start with: org.gnome.evolution.dataserver.Sources5[2521]: ** (evolution-source-registry:2716): WARNING **: secret_service_search_sync: must specify at least one attribute to match At that point calendar server starts flooding the logs with aforementioned message and start utilising 20% CPU It seems to be related to my gmail account because that is mentioned when i kill -HUP it: org.gnome.Shell.CalendarServer[2521]: (gnome-shell-calendar-server:2711): ShellCalendarServer-WARNING **: The calendar backend for 'dac.override' has crashed. org.gnome.Shell.CalendarServer[2521]: (gnome-shell-calendar-server:2711): ShellCalendarServer-CRITICAL **: create_client_for_source: assertion 'client == NULL' failed
I suppose you configured that account using GNOME Online Accounts. Could you verify in the Settings->Online Accounts, that the account is defined properly there? Aka there is not shown any issue or a request to reassign to it. Seahorse may also show you what passwords (credentials) you've stored, though the secret_service_search_sync() runtime warning suggests that there's something odd with the associated .source file in the evolution.
The account seems to be configured properly, but i to be sure i re-did it a few times. Seahorse show the keys properly and i haven't noticed any anomalies there. I also removed the ~/{.cache,.config,.local/share}/evolution a couple of times but no effects. These "infinite loop messages" start happening two hours after i booted (like clockwork).
(In reply to dac.override from comment #11) > The account seems to be configured properly, but i to be sure i re-did it a > few times. Just in case, it is configured in GOA, not directly in the evolution, right? > These "infinite loop messages" start happening two hours after i booted > (like clockwork). Do you mean like after the time you set the calendar's refresh interval to? Could you check content of ~/.config/evolution/sources/ and ~/.cache/evolution/sources/ for the files referencing this concrete calendar (the file will have a [Calendar] section in it), sanitize it from any private information (like email addresses and server addresses) and then attach it here, thus I could check whether there isn't anything suspicious in its content, please? I tried to setup a similar conditions as you have, and set a refresh interval to two hours for the Google calendar. Maybe I'll trigger it too. Otherwise my experience with gnome-calendar was different: when I run it, it ate significant part of CPU, until I closed it again.
(In reply to Milan Crha from comment #12) > (In reply to dac.override from comment #11) > > The account seems to be configured properly, but i to be sure i re-did it a > > few times. > > Just in case, it is configured in GOA, not directly in the evolution, right? Right, I do not have evolution installed. I use gnome-calendar for the calendar, gnome-contacts for contacts, and thunderbird and/or mutt for e-mail > > > These "infinite loop messages" start happening two hours after i booted > > (like clockwork). > I mean when i boot up the system, then when i wait for 2 hours, the "infinite loop" messages start occuring and cpu usage surges. > Do you mean like after the time you set the calendar's refresh interval to? > > Could you check content of ~/.config/evolution/sources/ and > ~/.cache/evolution/sources/ for the files referencing this concrete calendar > (the file will have a [Calendar] section in it), sanitize it from any > private information (like email addresses and server addresses) and then > attach it here, thus I could check whether there isn't anything suspicious > in its content, please? output of cat ~/.config/evolution/sources/*.source: http://paste.fedoraproject.org/315655/39728631/ > > I tried to setup a similar conditions as you have, and set a refresh > interval to two hours for the Google calendar. Maybe I'll trigger it too. > Otherwise my experience with gnome-calendar was different: when I run it, it > ate significant part of CPU, until I closed it again.
As for gnome-calendar, yes with it on the foreground it runs up to 20% cpu and drags gnome-shell and xorg with it: top: 3106 kcinimod 20 0 2054120 62752 17224 S 29.9 0.8 0:29.64 evolution-calen 2840 kcinimod 20 0 1868164 137156 58724 R 22.3 1.7 0:39.48 gnome-shell 6128 kcinimod 20 0 1534472 41984 28804 R 21.9 0.5 0:05.64 gnome-calendar 2675 kcinimod 20 0 300156 55696 43564 S 18.3 0.7 0:33.37 Xorg When i put gnome-calendar in the background (another workspace) then xorg, gnome-shell and gnome-calendar with return to normal utilization
snippet for just yet: Jan 28 10:25:06 void org.gnome.evolution.dataserver.Sources5[2724]: ** (evolution-source-registry:2919): WARNING **: secret_service_search_sync: must specify at least one attribute to match Jan 28 10:25:09 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3880022a0 stuck in infinite loop? (... times N) Jan 28 10:26:57 void /usr/libexec/gdm-x-session[2668]: Activating service name='org.gnome.Calendar' Jan 28 10:26:57 void /usr/libexec/gdm-x-session[2668]: Successfully activated service 'org.gnome.Calendar' Jan 28 10:26:57 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3a400c8c0 stuck in infinite loop? (... times N) Jan 28 10:27:32 void kernel: perf interrupt took too long (2540 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 Jan 28 10:27:33 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3a400c8c0 stuck in infinite loop? (... times N) Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkWindow' Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkWidget' Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): Gtk-CRITICAL **: gtk_widget_get_window: assertion 'GTK_IS_WIDGET (widget)' failed Jan 28 10:28:43 void kernel: gnome-calendar[6128]: segfault at 28 ip 0000560c3b7864c0 sp 00007fff0eb4ec68 error 4 in gnome-calendar[560c3b768000+54000] Jan 28 10:28:43 void kernel: audit: type=1701 audit(1453973323.895:2479): auid=1000 uid=1000 gid=1000 ses=1 subj=wheel.id:wheel.role:wheel_gcal.subj:s0-s0:c0.c1023 pid=6128 comm="gnome-calendar" exe="/usr/bin/gnome-calendar" sig=11 Jan 28 10:28:43 void audit[6128]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=1 subj=wheel.id:wheel.role:wheel_gcal.subj:s0-s0:c0.c1023 pid=6128 comm="gnome-calendar" exe="/usr/bin/gnome-calendar" sig=11 Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): Gdk-CRITICAL **: gdk_window_get_state: assertion 'GDK_IS_WINDOW (window)' failed Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GcalWindow' Jan 28 10:28:43 void org.gnome.Calendar[2724]: (gnome-calendar:6128): Gtk-CRITICAL **: gtk_window_get_application: assertion 'GTK_IS_WINDOW (window)' failed Jan 28 10:28:44 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff3a400caa0 stuck in infinite loop? (... times N) Jan 28 10:28:53 void systemd-coredump[6521]: Process 6128 (gnome-calendar) of user 1000 dumped core. Stack trace of thread 6128: #0 0x0000560c3b7864c0 gcal_application_get_settings (gnome-calendar) #1 0x0000560c3b789673 save_geometry (gnome-calendar) #2 0x00007fc49049b893 g_timeout_dispatch (libglib-2.0.so.0) #3 0x00007fc49049ae3a g_main_context_dispatch (libglib-2.0.so.0) #4 0x00007fc49049b1d0 g_main_context_iterate.isra.29 (libglib-2.0.so.0) #5 0x00007fc49049b27c g_main_context_iteration (libglib-2.0.so.0) #6 0x00007fc490a85a0c g_application_run (libgio-2.0.so.0) #7 0x0000560c3b77e0b0 main (gnome-calendar) #8 0x00007fc48f5ea580 __libc_start_main (libc.so.6) #9 0x0000560c3b77e0f9 _start (gnome-calendar) Stack trace of thread 6129: #0 0x00007fc48f6c0fdd poll (libc.so.6) #1 0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0) #2 0x00007fc49049b27c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fc48246f2ad dconf_gdbus_worker_thread (libdconfsettings.so) #4 0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fc48fba960a start_thread (libpthread.so.0) #6 0x00007fc48f6cca4d __clone (libc.so.6) Stack trace of thread 6139: #0 0x00007fc48f6c0fdd poll (libc.so.6) #1 0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0) #2 0x00007fc49049b4f2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fc494e80673 cal_client_dbus_thread (libecal-1.2.so.19) #4 0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fc48fba960a start_thread (libpthread.so.0) #6 0x00007fc48f6cca4d __clone (libc.so.6) Stack trace of thread 6130: #0 0x00007fc48f6c0fdd poll (libc.so.6) #1 0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0) #2 0x00007fc49049b27c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fc49049b2b9 glib_worker_main (libglib-2.0.so.0) #4 0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fc48fba960a start_thread (libpthread.so.0) #6 0x00007fc48f6cca4d __clone (libc.so.6) Stack trace of thread 6131: #0 0x00007fc48f6c0fdd poll (libc.so.6) #1 0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0) #2 0x00007fc49049b4f2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fc490abc336 gdbus_shared_thread_func (libgio-2.0.so.0) #4 0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fc48fba960a start_thread (libpthread.so.0) #6 0x00007fc48f6cca4d __clone (libc.so.6) Stack trace of thread 6133: #0 0x00007fc48f6c0fdd poll (libc.so.6) #1 0x00007fc49049b16c g_main_context_iterate.isra.29 (libglib-2.0.so.0) #2 0x00007fc49049b4f2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fc493046a34 source_registry_object_manager_thread (libedataserver-1.2.so.21) #4 0x00007fc4904c1835 g_thread_proxy (libglib-2.0.so.0) #5 0x00007fc48fba960a start_thread (libpthread.so.0) #6 0x00007fc48f6cca4d __clone (libc.so.6) Jan 28 10:28:53 void org.gnome.evolution.dataserver.Calendar7[2724]: (evolution-calendar-factory-subprocess:3106): libsoup-WARNING **: SoupMessage 0x7ff39003f8b0 stuck in infinite loop? (...times N) (me putting it out of its misery with kill -HUP PID) Jan 28 10:30:49 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-WARNING **: The calendar backend for 'Feestdagen in Nederland' has crashed. Jan 28 10:30:49 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-WARNING **: The calendar backend for 'Verjaardagen' has crashed. Jan 28 10:30:49 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-WARNING **: The calendar backend for 'dac.override' has crashed. Jan 28 10:30:51 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-CRITICAL **: create_client_for_source: assertion 'client == NULL' failed Jan 28 10:30:52 void gnome-keyring-daemon[2619]: asked to register item /org/freedesktop/secrets/collection/login/16, but it's already registered Jan 28 10:30:52 void org.gnome.Shell.CalendarServer[2724]: (gnome-shell-calendar-server:2914): ShellCalendarServer-CRITICAL **: create_client_for_source: assertion 'client == NULL' failed
(In reply to dac.override from comment #13) > output of cat ~/.config/evolution/sources/*.source: Thanks, though it's hard to recognize where one source starts and another ends. The file name is used as a unique identifier of it, thus they are sort of important too. The files in ~/.cache/evolution/sources/<some-uid>/ are the respective associated sources for the GOA account, like the calendars. The ~/.config/goa-1.0/accounts.conf contains [Account account_1453914525_1] section, which holds what you've enabled and what not and some user details. You might have it similar to what I have (with different account name), thus: [Account account_1445926770_0] Provider=google Identity=user PresentationIdentity=user MailEnabled=false CalendarEnabled=true ContactsEnabled=false ChatEnabled=false DocumentsEnabled=false PhotosEnabled=false FilesEnabled=false PrintersEnabled=false I see one difference in what you have in the pastebin and what I have in the same .source file (that with [GNOME Online Account] section). Your file contains [Authentication] Host= Method=none while mine has that [Authentication] Host= Method=OAuth2 The Method=none is not correct for GOA accounts accessing Google, it should read OAuth2. The calendar source (in ~/.cache/evolution/sources/<uid>) can have it differently. I have there OAuth2 too.
I had configured Google account in Gnome's "Online accounts" and at some point (like a day or 2 ago) started to see evolution-calendar-factory-subprocess consuming ~25% of CPU plus other related (?) processes were eating other CPUs as well. Now I disabled all items in that "Online Account" (i.e. I didn't deleted it but nothing gets synced now) and magically all extra CPU loads went away.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Hi, I'm experiencing exactly the same issue on a regular basis (feels like every one-two days). * Fedora 26 Alpha * Evolution 3.24.2-1.fc26 I'm not actively using Evolution when I get aware of the issue, but I think I used it some time before. I only get notified by a loud CPU fan. Just killed the process, but here are some pastes: Output of ~/.local/evolution/sources/*.source: https://pastebin.com/eh8hpXxB Output of ~/.cache/evolution/sources/*.source: https://pastebin.com/ZhiLwjy1 I configured the mail accounts through "Online Accounts" at first, which caused strange issues like freezing Evolution completly. Now I configured the accounts through Evolution directly, which works much better (but still not perfect). Just let me know if I can provide more information.
Thanks for the update. If I read it properly, then you've an EWS account and and IMAPx account and that EWS account contains quite many address books, one memo list, one task list, and like 5 calendars. I suppose the high CPU usage is caused by the EWS calendars, but to be sure a: $ ps ax | grep evolution shows also arguments for the binaries, where --factory argument for an evolution-calendar-factory-subprocess tells which of them is running in it. After that, a backtrace of the running high-CPU-consuming process would be nice to have, even several of them, to see what it does or tries to do. Comment #2 contains a gdb command to do so. Please, install also debuingo package for evolution-ews, apart of evolution-data-server mentioned there, thus the backtrace is usable.
I made this [1] change for evolution-data-server 3.24.3+. I cannot tell whether it'll help in your case (because I do not know what that issue is), but it is supposed to help in an instance of the issue I accidentally faced. [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=d4d9f16
I played with my calenders and address books, but I'm currently unable to reproduce the issue. Should I be successfull, I will provide your requested debug data and try your patch (thanks for that!). One different issue I found though is that activating other calenders (from collegues) will add those appointments to my system calender and reminders... which is in theory correct, but there should be an option to prevent that (I sometimes just want to look around in other calenders of my company). But this is surely another issue.
(In reply to Thomas Vollstädt from comment #23) > One different issue I found though is that activating other calenders (from > collegues) will add those appointments to my system calender and > reminders... which is in theory correct, but there should be an option to > prevent that (I sometimes just want to look around in other calenders of my > company). But this is surely another issue. Edit->Preferences->Calendar and Tasks->Reminders tab - check which to use for reminders and which not. Calendar view itself is clear, you can check/uncheck calendars there, and see only those checked.
(In reply to Milan Crha from comment #24) > Edit->Preferences->Calendar and Tasks->Reminders tab - check which to use > for reminders and which not. Calendar view itself is clear, you can > check/uncheck calendars there, and see only those checked. Unfortunately this doesn't work on my setup, appointments of unchecked calendars are still shown in the notification area of gnome-shell. Should I create a new ticket for this? Still no appearance of the original issue, I will keep an eye on it.
(In reply to Thomas Vollstädt from comment #25) > Unfortunately this doesn't work on my setup, appointments of unchecked > calendars are still shown in the notification area of gnome-shell. Should I > create a new ticket for this? Not needed, it means that it's another software showing the notifications. I do not know how to figure out which it is, though.