evolution-calendar-factory always running with high memory usage

To clarify, out of the box on krillin with no calendar sync even enabled, evolution-calendar-factory uses 32MB which is the 4th highest process in memory usage. This is with an empty database of no calendar events or alarms.

I'm assuming evolution-calendar-factory gets loaded by indicator-datetime initially such that the indicator can show calendar events.

If you have a large database of calendar entries (i.e. after you've done a google calendar sync), as Pat reported this process can grow to well over 100MB. It seems to have no upper bound, and since the evolution backend for calendar is simply a flat file of type .ics, e-c-f appears to load the entire file into memory.

e-c-f really needs a sqlite backend or something such that it can manage it more efficiently. Someone needs to investigate what can be done in the short term reduce the memory usage if possible.

Given that this would be a large amount of effort lets make this an OTA update fix.

Hopefully the situation will improve if Bug #1339016 delivers a more efficient Sync process.

Status changed to 'Confirmed' because the bug affects multiple users.

If anyone is interested in a workaround, here's something that seems to work on my Ubuntu install.

I noticed that running /usr/lib/evolution/evolution-calendar-factory by itself manually will cause it to perform some initializations and terminate after a few seconds. I'm not using any calendar-related services.

--------
Registering ECalBackendContactsEventsFactory ('contacts:VEVENT')
 <<snip>>
Registering ECalBackendCalDAVTodosFactory ('caldav:VTODO')
Server is up and running...
Bus name 'org.gnome.evolution.dataserver.Calendar4' acquired.
Bye.
--------

I also noticed that if I ran /usr/lib/evolution/evolution-calendar-factory while there is already an instance running, the new instance will take over the 'org.gnome.evolution.dataserver.Calendar4' bus and will cause the older one to terminate:

--------
Registering ECalBackendContactsEventsFactory ('contacts:VEVENT')
 <<snip>>
Registering ECalBackendCalDAVTodosFactory ('caldav:VTODO')
Server is up and running...
Bus name 'org.gnome.evolution.dataserver.Calendar4' acquired.
 <<launch another instance in another terminal>>
Bus name 'org.gnome.evolution.dataserver.Calendar4' lost.
Bye.
--------

Since I'm not using any calendar-related services, I added a startup item via GUI that invokes /usr/lib/evolution/evolution-calendar-factory without any options:

--------
> cat ~/.config/autostart/evolution-calendar-factory.desktop

[Desktop Entry]
Type=Application
Exec=/usr/lib/evolution/evolution-calendar-factory
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Workaround for evolution-calendar-factory
--------

This causes the original "stuck" startup process to lose its hold on org.gnome.evolution.dataserver.Calendar4 and terminate.

This workaround is a lot less invasive than the suggestions I have seen elsewhere to uninstall packages or remove the file's execute bit, since org.gnome.evolution.dataserver.Calendar4 will still be available.

Again, this is a workaround. Unfortunately, I haven't been able to find out what causes the process to be stuck in the first place, or whether or not it really needs to run all the time.

Small update:

> Bill Filler (bfiller) wrote on 2014-09-23:
> I'm assuming evolution-calendar-factory gets loaded by indicator-datetime initially such that the indicator can show calendar events.

As a troubleshooting step, I tried disabling the Upstart entry for indicator-datetime-service so that it doesn't get started and respawned automatically, and launched it manually using the terminal. Sure enough, evolution-calendar-factory starts only after indicator-datetime-service starts, and stops a few seconds after the indicator-datetime-service process is terminated (by Ctrl-C during my testing).

So what actually happens in the workaround I posted earlier was that invoking another instance of evolution-calendar-factory manually will sever the link that the date/time indicator has to the calendar service. The new, manually invoked evolution-calendar-factory instance that replaced the old one will then terminate itself after a few seconds.

It should be fine for people like me who never use the calendar, but people who do use the calendar should watch out.

There are a few questions I can think of at this point:
1. Is it by design that indicator-datetime-service needs continuous access to the org.gnome.evolution.dataserver.Calendar4 D-Bus service?
2. Does it really need to maintain a connection to that service even if the user doesn't use the calendar feature at all? (this needs to be asked because the current implementation of evolution-calendar-factory occupies an above-average amount of memory, even for empty calendars)
3. If not, what could be preventing it from disconnecting from the service once it's done with its business?

I'll try to see what else I can uncover.

@aj-sahagun
I have the exact same problem. Adding an autostart entry did not help, for reasons I do not understand. If I type it manually in a terminal, it works fine. If I add an autostart entry with the exact same command, nothing happens and evolution-calendar-factory happily nibbles away at RAM. I even tried to autostart with "sleep 60; /usr/lib/evolution/evolution-calendar-factory", unfortunately to no avail.
Am I missing something here ?
- - - - - - -
ledoc@kuro:~$ cat ~/.config/autostart/evolution-calendar-factory.desktop
[Desktop Entry]
Type=Application
Exec=sleep 60; /usr/lib/evolution/evolution-calendar-factory
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[fr_FR]=Workaround for evolution-calendar-factory
Name=Workaround for evolution-calendar-factory
Comment[fr_FR]=Temporary workaround until the bug is corrected
Comment=Temporary workaround until the bug is corrected
- - - - - - -

Had lost track of this one but still relevant

@ledoc

Hi Eric, same as you, I later realized that a certain delay was needed for it to work reliably, since there'd be times when the autostart entry would get invoked before the datetime indicator. The Exec line on my .desktop file now reads like this:

Exec=bash -c 'sleep 1m; /usr/lib/evolution/evolution-calendar-factory'

An Upstart-based solution might be better given that timing is involved, but this simple approach works well enough for me. Perhaps you'd like to try it out?

@aj-sahagun

Thanks for your reply. I wasn't aware you had to explicitly call bash when using the form "sleep 1m; <command>". I'll try it out.

@aj-sahagun

Works fine now. So apparently, when you want a couple of commands to be launched one after the other in the startup list, you can't just write:

    sleep 60; <command>

You have to explicitly call bash -c like this:

    bash -c 'sleep 60; <command>'

Good to know!

Seems still true on 16.04 final beta. A lot of large evolution-calendar-factory processes.

Still present. Updated 16.04, 100MB (3 processes) for calendar that I can't even use (doesn't support yahoo sync).

+1 after update on 16.04. Unfortunately, at the end the swap is important on my PC so it slow down.

Still a major memory hog in 16.04 with a clean install (except for /home obviously).
The process has changed names and is now dubbed "evolution-calendar-factory-subprocess" but its behavior has not changed. After a couple of minutes, memory usage is up to ~300 Mio, which is a bit steep for something that's not even wanted…

Plus, the nice little workaround does not seem to function in 16.04. Simply re-invoking the process does not lead to it exiting. I've seen it crash several times in a row with no obvious pattern to it (except it happens fairly soon after login).

hmm, this bug seems ot have been dragged away from the actual topic by the audience, please note that this bug talks about phone and tablet installs (as the "Canonical System Image" task implies) where we use a reduced and slightly different installation compared to desktops (and definitely no support for things like ~/.config/autostart and such).

if you have issues with evolution-data-server on a desktop install your chances are way higher to have some desktop people look at it if you file a new bug.

@ogra Thanks, I wasn't at all aware that "Canonical System Image" was about *mobile* systems. Maybe a more straightforward name would help… :)
I'll go look if this bug has already been filed under desktop installs.

New bug filed under Bug #1589605 for the desktop install.

still getting this bug on 16.04
it has 3 process over 40mb each!

maybe it's possible to remove it completely?

Upstream problem. Fixed in eds >= 3.22