e-d-s does not exit with gnome-session

[Gert Kulyk]

Binary package hint: evolution-data-server

E-d-s stays active after session logout, breaking e.g. gnome-settings-daemon after re-login without killing e-d-s explicitly on console. Encountered this Problem first time in Edgy, after updating to Feisty today nothing changed.

Update: The breakage of things after re-login is related to a still running bonobo-activation-server, which seems to be caused by e-d-s (killing e-d-s kills bonobo-activation-server, too). Any hint how to debug - or even better - how to fix this?

[Sebastien Bacher (seb128)]

Thank you for your bug. I don't confirm the bug, that works fine on my feisty destkop. could you get a backtrace (https://wiki.ubuntu.com/DebuggingProgramCrash) for evolution-data-server when it's hanging?

[Gert Kulyk (gkulyk)]

I'll post it later. What do you think, would it be better starting it in terminal via strace or attaching strace to a running evolution-data-server?

Hints for reproducing: It seems like it only occurs, when accessing calendar-component. When not clicking to clock-applet (but occurs too, when clock-applet is removed from panel) and/or not opening calendar-component, e-d-s seems to exit with session cleanly.

[Sebastien Bacher (seb128)]

attaching the running process is easier

[Gert Kulyk (gkulyk)]

Here is a strace-output. Strace was attached to an running e-d-s process, which was started via evolution (from office-menu). It started showing calendar. Then attached strace to pid, then opened evo back with calendar component, taking a look to the next month, then closing and exiting session. Afterwards I waited a bit more than a minute and then killed e-d-s, which was still running after logout.

[Sebastien Bacher (seb128)]

Could you get a backtrace with gdb as described on the wiki?

[Gert Kulyk (gkulyk)]

I'll try it later, but I'm not really sure how to use gdb on a process that is not really crashing - it simply stays active, in theory (if it would not keep open bonobo-activation-server what does harm to some applets (gswitchit etc) it could be re-used after re-login.

The former strace-output seems not to be the best for finding out what is going wrong, starting e-d-s from terminal with strace directly I got some error messages, which seem to be a bit more helpful.

---
Especially the following lines seem to be interesting:
09:21:33.882038 write(2, "\n(evolution-data-server:7683): G"..., 112
(evolution-data-server:7683): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
) = 112
09:21:33.882138 write(2, "\n(evolution-data-server:7683): l"..., 148
(evolution-data-server:7683): libedata-cal-CRITICAL **: e_cal_backend_internal_get_default_timezone: assertion `E_IS_CAL_BACKEND (backend)' failed
) = 148
09:21:33.882250 write(2, "\n(evolution-data-server:7683): G"..., 113
(evolution-data-server:7683): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
) = 113
---

Please note: After setting up evolution on a clean account, everything went well untill I set up birthday-calendar events. Same seems to be true when tasks or other events are added.

[Gert Kulyk (gkulyk)]

When using hints for using gdb as described in the wiki with eds, it does nothing but waiting for a crash, which does not occur. gdb keeps running, eds keeps running, nothing is happening. Which option do I have to pass to get a usefull output (so it only prints messages about the loading of symbols and the message continuing).

[Gert Kulyk (gkulyk)]

I still do not have any idea how to get a backtrace from processes that are not crashing - ok b-a-s is crashing, but only after a re-login because of conflicts with a newly started instance of it.

Are you sure you can't reproduce it? I've tried it again and again, on a clean account (=default ubuntu-desktop-settings, I've even tried locale en_US) but configured evolution with birthday-calendar (same for a single task or a repeating event). Always when trying to re-login, b-a-s and e-d-s are still running, b-a-s breaking some applets, e-d-s lingering around, because a new instance is opened.

If you still say you cannot reproduce it, I'll try a fresh system-install (I'm updating this computer since breezy, always more or less painless).

[Gert Kulyk (gkulyk)]

After some research, I found http://bugzilla.gnome.org/show_bug.cgi?id=268533, it seems a bit similar to this (although it is marked fixed for 1,5 years now).

attaching gdb to the running e-d-s-process, I get the following:

---
(gdb) print e_data_cal_factory_get_n_backends(e_data_cal_factory)
$1 = 0
(gdb) print e_data_book_factory_get_n_backends(e_data_book_factory)
$2 = 3
---
Note: I have configured 3 Adress-Books on the current account, all seem to be kept open by something even after logout from session.

[Gert Kulyk (gkulyk)]

I found an ugly workaround. When I move the file /usr/lib/evolution-data-server-1.2/extensions/libecalbackendcontacts.so out of the way, e-d-s and b-a-s are shutting down properly. Something in this backend seems to be broken.

[Sebastien Bacher (seb128)]

Thank you for your work on that. I've forwarded it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=420167

[Michael Hofmann (mh21)]

This causes the drivemount-applet to stop working when you relogin because it does not get the right dbus env variable from bonobo-activation-server which makes it impossible to communicate with the session bus.

[Markus Kienast (elias1884)]

Many things don't work after relogin due to this bug. This bug keeps me from upgrading my LTSP environment to Feisty! Relogins occur frequently in such an environment. Please put some pressure on the Gnome guys to fix this bug. For edubuntu this could have been considered a release critical bug.

[Nicolò Chieffo (yelo3)]

sorry but do you think that this is caused by e-d-s? these are my remaining procseses after a logout:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
yelo3 5082 0.0 0.6 40840 3228 ? Ssl 13:56 0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=13
yelo3 5212 0.0 1.1 82312 5932 ? Sl 13:56 0:00 /usr/lib/evolution/evolution-data-server-1.12 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=29
yelo3 16326 0.0 0.4 4932 2200 ? S 16:20 0:00 /usr/lib/libgconf2-4/gconfd-2 14

after killink the first process everything seems to be ok after the login....

[Gert Kulyk (gkulyk)]

Yes, it's e-d-s. Bonobo-activation-server is causing the troubles after re-login, but it is kept open by e-d-s. When killing b-a-s only, you can re-login without problems, but there will remain an instance of e-d-s. You'll see, that killing e-d-s will shut-down b-a-s.

[Nicolò Chieffo (yelo3)]

Mmmmmm strange...
This is what I've done.
created new user
login, added the drivemount-applet (to check this bug)
logout.

ps uxw shows

chievo 6384 0.3 0.6 40840 3248 ? Ssl 19:51 0:00
/usr/lib/bonobo-activation/bonobo-activation-server --ac-activate
--ior-output-fd=16
chievo 6597 0.1 0.4 4932 2176 ? S 19:52 0:00
/usr/lib/libgconf2-4/gconfd-2 14

so nothing about evolution-data-server...

after some minutes I executed again ps uxw and obtained ONLY the
bonobo line (so gconfd was down)

then I did my login and the bug was there (the drivemount-applet didn't show)

So are you still sure that the bug is caused by evolution-data-server
rather than bonobo-activation-server?

[Nicolò Chieffo (yelo3)]

though it happened, now it does not happen anymore that the bonobo
server stays alive... Maybe I did something that triggered it, in the
bugged session...

[Sebastien Bacher (seb128)]

there is a evolution-data-server bug most likely, you might run into an another bug though

[Nicolò Chieffo (yelo3)]

all right

[Cedric Schieli (cschieli)]

Oops, I've propagate this bug here by mistake.
Please ignore.

[Alexander Oltu (sazs)]

I experience same problem. After session logout b-a-s and e-d-s remains in memory.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
sazs 5147 0.2 0.6 39644 3152 ? Ssl 09:51 0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=16
sazs 5344 0.2 2.1 77616 10308 ? Sl 09:51 0:00 /usr/lib/evolution/evolution-data-server-1.10 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=34

i blaming e-d-s for that as after killing e-d-s b-a-s shutdowns also. Also upstream it is marked as major now.

[Markus Kienast (elias1884)]

I am happy to hear, the bug is marked major in upstream now! I am glad
finally somebody realises this is not just an inconvenience but stops
the product from being used in production environments!

[Markus Kienast (elias1884)]

I am happy to hear, the bug is marked major in upstream now! I am glad finally somebody realizes this is not just an inconvenience but stops the product from being used in production environments! It reduces Feisty release to be a BETA release, not usable professionally!!!!!

Maybe finally the bug will be marked "high priority" in Ubuntu as well some day!

[Sebastien Bacher (seb128)]

elias, exageration is of no use, the bug is not a real problems for many users. Anyway what it lacking is not anybody realizing that the bug should be fixed, that was already the case, rather somebody working on it. There is thousand of evolution bugs open and very few hackers on it

[DWHagar (david-hagar)]

Well, I have found that on my system something else is at least a contributing factor, I am at a loss for how to track this though as bonobo-activation-server stays on after logout and log back in time after time with no other processes running. I can kill the process, but isn't it supposed to shut itself off when I log out?

[Gert Kulyk (gkulyk)]

To Elias:

I have to agree with Sebastien. There is a possibility to get it to work (renaming/deleting libecalbackendcontacts.so), with the problem, that it breaks the birthday-notification feature of evolution, which, if this was a default behavior of the Ubuntu-Package, would cause another bug-report of people, who are using this feature on a single-user-system (maybe one of the most common scenarios).

The code of e-d-s is a bit to complex to fix it "by the way" (or can you do it?). This is not a Ubuntu-Specific bug, every distribution which is using latest e-d-s is affected, so the issue has to be fixed upstream. Upstream is doing a lot of code-cleanups and code-review at the moment, so even a bug marked with the priority "major" is not fixed from one day to another (especially, like Sebastien mentioned before, there are only a few persons working on it).

Marking this bug with priority "high" would not change anything, as long as noone is contributing a piece of code or a bounty to get it fixed. I can understand you to be annoyed by this specific bug (as I was and as I am), but there will always be things that are not working "out of the box" as expected, because you cannot write 100% bug-free software and/or the author of a piece of code cannot test it on all possible combinations of soft- and hardware.

[Gert Kulyk (gkulyk)]

After further inverstigation of the problem, I've found another workaround. As stated above, a similar, if not the same, issue existed before (http://bugzilla.gnome.org/show_bug.cgi?id=268533). Fedora/Redhat therefore provided a patch to workaround the issue. They were patching src/server.c, where the following test is made:

if (e_data_cal_factory_get_n_backends (e_data_cal_factory) == 0 &&
     e_data_book_factory_get_n_backends (e_data_book_factory) == 0) {
  g_message ("termination_handler(): Terminating the Server. Have a nice day.");
  bonobo_main_quit ();
 }

As above stated, the condition is never reached because of "e_data_book_factory_get_n_backends (e_data_book_factory)" is never returning a value equal zero, so bonobo_main_quit () is never called.

The (slighly modified, because they had to deal only with one open addressbook) additional test they applied looks like this:

if (e_data_cal_factory_get_n_backends (e_data_cal_factory) == 0 &&
     e_data_book_factory_get_n_backends (e_data_book_factory) > 0) {
  g_message ("termination_handler(): Terminating the Server (with workaround for bug 420167). Have a nice day.");
  bonobo_main_quit ();
 }

This would at least cause e-d-s to shut down. I know this is not really fixing the cause of the issue (I do not have the skills to do that), but something like that would in my opinion be more sane than beeing forced to kill the server before you can do a re-login. What are you thinking about something like that? For me this works perfectly. If you want, I can provide a patch/debdiff/testpackage, whatever you want if you need it.

[Gert Kulyk (gkulyk)]

You can find the mentioned fedora-patch here: http://cvs.fedora.redhat.com/viewcvs/rpms/evolution-data-server/FC-6/evolution-data-server-1.0.2-workaround-cal-backend-leak.patch?root=core&rev=1.1&view=auto
modified version to respect the fact that e-cal-backend-contacts is leaking more than one addressbook attached.

[David Planella (dpm)]

@ Pedro Villavicencio:

why was the status of this bug, which has also been confirmed upstream, been changed from "Confirmed" to "Triaged" without a comment?

Maybe I'm interpreting wrongly what "Triaged" means, but I do not see a reason to change its status when it has been confirmed already.

[David Planella (dpm)]

I've just been pointed out to what "Triaged" means (effectively the new term for "Confirmed", if I understand it correctly), so my previous comment can be ignored.

[Markus Kienast (elias1884)]

Great! Guess what now it happening! When I logout and login again, literally all gnome applets refuse to be loaded!

[Sebastien Bacher (seb128)]

elias, what is the interest if your comment?

[Markus Kienast (elias1884)]

I am just wondering if the changes which have been made to e-d-s or actually the plugins themselves to conform to the way e-d-s works as mentioned above somewhere, are now causing all plugins to not work anymore after relogin. I am filed an extra bug for this and will verify if this has anything to do with e-d-s.

I was just stunned today, that what I tried to express with my comment. I was expecting the plugins to work now, but instead non of them worked anymore after relogin.

[Sebastien Bacher (seb128)]

evolution-data-server (1.12.0-0ubuntu5) gutsy; urgency=low

  * debian/patches/80_from_bugzilla_fix_reference_counting.patch:
    - patch from GNOME bug #420167, fix some reference counting issues which
      made evolution-data-server not exit properly with the session and create
      issues to the next user login
      (LP: #90258)

 -- Sebastien Bacher <email address hidden> Sat, 06 Oct 2007 13:09:44 +0200

[Markus Kienast (elias1884)]

On Sat, 2007-10-06 at 12:03 +0000, Sebastien Bacher wrote:
> evolution-data-server (1.12.0-0ubuntu5) gutsy; urgency=low
>
> * debian/patches/80_from_bugzilla_fix_reference_counting.patch:
> - patch from GNOME bug #420167, fix some reference counting issues which
> made evolution-data-server not exit properly with the session and create
> issues to the next user login
> (LP: #90258)
>
> -- Sebastien Bacher <email address hidden> Sat, 06 Oct 2007 13:09:44
> +0200
>
> ** Changed in: evolution-data-server (Ubuntu)
> Status: Triaged => Fix Released
>

I hope this fix will make it into Gutsy even though it came so late in
the release schedule!

[Sebastien Bacher (seb128)]

the bug has been closed for a reason, this upload has been accepted to gutsy

[Gert Kulyk (gkulyk)]

Great news, thanks a lot. Now I'm no longer forced to patch the package on my own.

[Sebastien Bacher (seb128)]

Let we know how the upgrade works for you

[Gert Kulyk (gkulyk)]

Of course. But if you really used Milans' patch, everything should work fine. I'm actually running a build based on the ubuntu package with the bugzilla-patch applied.

[Gert Kulyk (gkulyk)]

Works like a charm, many thanks.

[Stefan.Vogt (stefan-vogt)]

Works absolutely great for me now. Thanks a lot!

[Timo Aaltonen (tjaalton)]

I've tested this with feisty, and it works great. What about putting this in feisty-updates?

[Markus Kienast (elias1884)]

Please disable automatic startup of "evolution alarm notifier" until this is fixed!

Some people like me are maintaining large LTSP environments and this damn thing screws up the hole system!

* When people log out, there are left over processes.
* They are unable to login again until I kill these processes.
* Alarm Notifier consumes all CPU

I attached a ps axu showing lots of user processes left over after logout. Non of the users listed was logged in, when this file was created. Pay special attention to users 1526, 1528 (names were to long to display) and haasd. Most of their processes did not stop on logout.

They can not log in anymore now! Until I get my hands on and kill their stuff.

The other users show the usual suspects:
scheidlc 17439 0.0 0.2 5340 2216 ? S 11:42 0:00 /usr/lib/libgconf2-4/gconfd-2 12
scheidlc 7864 0.0 0.2 31992 3048 ? Ssl May06 0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=16
scheidlc 7926 0.0 0.5 42448 5724 ? Sl May06 0:00 /usr/lib/evolution/evolution-data-server-2.22 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=22

This bug goes hand in hand with bug #151536. Two different problems, yes. But the same source.

Disabling Evolution Alarm Notifier solved this problem on my Laptop.
Having certain calendars enabled in Evolution especially the Birthday and Weather stuff seems to trigger some misbehaviour too, especially on the logout front.

I vote for getting rid of evolution all together. But as a quick fix, disable Evolution Alarm Notifier by default!

System info:
LTSP: 1 AMD K7 CPU (32bit)
Laptop: Some 32bit Celeron CPU pre DualCore

It would be so much easier and more accurate if I could just point you to the HW profiles of my systems, which could be attached to my launchpad profile if Canonical would fund and implement an idea outlined here:

http://brainstorm.ubuntu.com/idea/1497/
https://bugs.launchpad.net/malone/+bug/3382