GNOME Bugzilla – Bug 641396
gnome-shell hangs when evolution-data-server is not available
Last modified: 2011-02-28 21:10:39 UTC
With gnome-shell-2.91.6-3.fc15 and evolution-data-server-2.91.6-2.fc15 e-d-s is not available to gnome-shell for some reason. However, because of the new Date applet on the top bar of g-s, gnome-shell hangs waiting on data from e-d-s and user never gets working desktop on the start. THere is only background and nothing else. Situation when e-d-s is not available should be treated for somehow. I had to comment out these lines in /usr/share/gnome-shell/js/ui/panel.js (the first line 691): // /* center */ // this._dateMenu = new DateMenu.DateMenuButton(); // this._centerBox.add(this._dateMenu.actor, { y_fill: true }); // this._menus.addMenu(this._dateMenu.menu);
<davidz> mbarnes: the problem is that it sometimes block... for GNOME 2 this was less of a problem as it only meant that the clock applet didn't display.. for GNOME 3, it blocks everything.. including your WM I mean, even with a sync API it shouldn't block forever IIRC jrb was able to reproduce this if he enabled encryption or something we could probably run the libeds code in a dedicated thread in the shell but I don't know if libeds is thread-safe if it is, maybe we should at least to avoid completely blocking the WM <mbarnes> davidz: afaik, libecal is as thread-safe as GDBus is <mbarnes> but yeah, the blocking issue plagues us too <davidz> mbarnes: oh, in that case we should consider it (GDBus is 100% thread-safe) shouldn't be too much work to do the work in a thread <mbarnes> yeah, that's probably the best way for now replacing EBook and ECal with better APIs is on my list for this year
The "no timeout" thing could be caused by my recent change, where I did disable timeout on dbus calls done by EBook/ECal structures. Matej showed me his xsession-errors file and the caldav calendar is crashing for him for some reason. Let's start there.
Created attachment 180280 [details] screenshot of the situation one of possible reasons? Gnome pretends to support proxy.pac files, but not really.
two more datapoints: a) proxy.pac is probably a red herring, it hangs without any proxy set up, b) it is actually a problem somewhere around startup ... when I restarted gnome-shell later and e-d-s was already running, it worked without a problem.
Created attachment 181953 [details] [review] Patch that works (but also needs cleanup) Hey, I've been working on this the past couple of days. I ended up moving things out-of-process... anyway, the patch isn't completely cleaned up and I need to also write a few paragraphs about how things work. Either way, I'm submitting the patch now so people can check if it works. I'll finish it Monday, gotta run now. As an added bonus the patch also fixes bug 641057. To test it just apply the patch and run './gnome-shell --replace' (I'm not sure it's enough to just do alt+f2, then r because of the src/gnome-shell.in changes ..the patch installs machinery to start the helper if running uninstalled... thanks in advance for testing!
Created attachment 182117 [details] [review] Proposed patch Here's an updated patch. Changes from previous patch - Write an explanatory commit message describe why this change is needed as well as what the change entails - Force refreshing events when opening the calendar dropdown to possibly work around buggy e-d-s code (I observed a couple of times, on login, that no events were loaded) and to reactivate the helper process in the event it crashes (guards against buggy e-d-s code and buggy helper code) Please review. Thanks!
src/Makefile-calendar-server.am 5 6 $(service_DATA): $(service_in_files) Makefile 7 @sed -e "s|\@libexecdir\@|$(libexecdir)|" $< > $@ I rather religiously do: $< > $@.tmp && mv $@.tmp $@ On ext4 and BTRFS this is guaranteed to be "atomic". src/gnome-shell.in 255 subprocess.Popen([calendar_server_path]) 256 except OSError, e: 257 print "Failed to start %s: %s"% (calendar_server_path, e) Please start this from say shell-global.c; there are incoming patches to massively trim down and sanitize this script.
The C code looks superficially fine; I'm not familiar with the evo APIs, so I can't do a full review. Fine to commit after the above comments are addressed.
Created attachment 182123 [details] [review] Updated patch Updated patch fixing the issues mentioned in comment 7 and comment 8. I will push this to master momentarily.
Pushed as http://git.gnome.org/browse/gnome-shell/commit/?id=e9e30138bd617a410a60b45ac0a5576094ed63d4