The datahub starts zeitgeist-daemon on startup

Bug #772265 reported by Mikkel Kamstrup Erlandsen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zeitgeist Datahub
New
Undecided
Unassigned
Zeitgeist Framework
Invalid
Undecided
Unassigned
libzeitgeist
New
Undecided
Unassigned

Bug Description

We have been advising distros put zeitgeist-datahub into the autostart section for the sessions. This is better in theory because this way we only start a native daemon on login and can defer the launching of the heavier Python process zeitgeist-daemon.

Unfortunately zeitgeist-datahub does DBus activation of the zeitgeist-daemon on startup so we really don't get the benefits we wanted. Bootcharts from Ubuntu 11.04 indicates that ZG eats about 1s on the login time and I don't think that is acceptable for ZG in the longer run. That is - no catastrophe for 11.04, but we should fix this.

(a related issue seems to be that the dbus activated zeitgeist-daemon seems to launch another datahub instance that then immediately becomes a zombie... ? :-/)

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

I'm adding a libzeitgeist task as well here because it right now creating either a ZeitgeistLog or ZeitgeistIndex will DBus-activate zeitgeist-daemon. It's unclear to me what the consequences of not autostarting zeitgeist from these would be though...

And that said simply twiddling these two classes wont be the real fix since the datahub still queries a ZeitgeistDataSourceRegistry which naturally *requires* a running ZG daemon.

To really get to the bottom of this we might need to have libzeitgeist read a datasources.json file in order to circumvent the requirement for a running zeitgeist-daemon?

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

Some reference bedtime reading:

 - bug #731019 "Certification System 201101-7174 boots 7.93 seconds slower"
 - http://www.phoronix.com/scan.php?page=article&item=ubuntu_natty_boot&num=1

Revision history for this message
Markus Korn (thekorn) wrote :

The zombie part of this issue should be already fixed in lp:zeitgeist by using glib.spawn_async() instead of subprocess.Popen() (LP: #739780)

Revision history for this message
Seif Lotfy (seif) wrote : Re: [Bug 772265] Re: The datahub starts zeitgeist-daemon on startup

I am pretty sure the datasources are stored in a pickle
maybe we need to open a bug to move the pickled stuff into json file.

On Thu, Apr 28, 2011 at 12:58 PM, Markus Korn <email address hidden> wrote:

> The zombie part of this issue should be already fixed in lp:zeitgeist by
> using glib.spawn_async() instead of subprocess.Popen() (LP: #739780)
>
> --
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
> https://bugs.launchpad.net/bugs/772265
>
> Title:
> The datahub starts zeitgeist-daemon on startup
>
> Status in Zeitgeist Client Library:
> New
> Status in Zeitgeist Framework:
> New
> Status in Zeitgeist Datahub:
> New
>
> Bug description:
> We have been advising distros put zeitgeist-datahub into the autostart
> section for the sessions. This is better in theory because this way we
> only start a native daemon on login and can defer the launching of the
> heavier Python process zeitgeist-daemon.
>
> Unfortunately zeitgeist-datahub does DBus activation of the zeitgeist-
> daemon on startup so we really don't get the benefits we wanted.
> Bootcharts from Ubuntu 11.04 indicates that ZG eats about 1s on the
> login time and I don't think that is acceptable for ZG in the longer
> run. That is - no catastrophe for 11.04, but we should fix this.
>
> (a related issue seems to be that the dbus activated zeitgeist-daemon
> seems to launch another datahub instance that then immediately becomes
> a zombie... ? :-/)
>

Revision history for this message
Markus Korn (thekorn) wrote :

I'm not a big friend of the idea to allow someone else than the daemon itself modify config files like datasources.(pickle|json), because this would require the daemon to watch-out for changes to all config files it and its extensions are using.

libzeitgeist and the datahub should instead defer any communication to the daemon until before the first event is inserted, e.g. the datahub should register itself as a datasource only once it inserts the first event. This doesn't necessarily solve the initial issue of this bugreport (zg slowing down login time) but it's a start. In a next step we have to make sure that the datahub inserts events as late as possible, *not during session login*.

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

On 28 April 2011 14:24, Markus Korn <email address hidden> wrote:
> I'm not a big friend of the idea to allow someone else than the daemon
> itself modify config files like datasources.(pickle|json), because this
> would require the daemon to watch-out for changes to all config files it
> and its extensions are using.

I am not suggesting that clients modify anything. That would be very
racy. I am suggesting that clients have access to an API that reads
and parses this file under the hood (ie. the file is considered
internal private "API" to Zeitgeist, but dedicated libs are allowed to
access it).

I think we may wanna move in this direction too anyway if/when we
enable WAL on the main db which can allow clients direct read-only
access to the db (still through our APIs ofcourse, but avoiding the
dbus roundtrips).

Revision history for this message
Michal Hruby (mhr3) wrote :

@Mikkel: Could you check gio's AppLaunched signal? I mean all of this can be done in vain if any AppLaunched signal is fired during the session start.

Revision history for this message
Siegfried Gevatter (rainct) wrote :

Closing the Zeitgeist task of this since it seems to be a datahub thing.

Changed in zeitgeist:
status: New → Invalid
Revision history for this message
Siegfried Gevatter (rainct) wrote :

Is this still an issue now that Zeitgeist has been ported to Vala?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.