D-Bus core due for a release?
hp at redhat.com
Wed May 16 15:46:33 PDT 2007
Tim Dijkstra wrote:
> On Wed, 16 May 2007 14:41:29 -0400
> Havoc Pennington <hp at redhat.com> wrote:
>>> * possibly the user database (it's unclear whether this made it into 1.0.2)
>> Not sure I remember the current state here, but I thought there was a
>> patch that needed some performance testing before we put it in.
> Part of it is cleanup; there used to be two copies of the cache, also
> they didn't got expired on dbus reload. The second part is a configure
> switch to disable it altogether, which is the correct thing to do IMHO.
> It will indeed hit performance if you use for example an LDAP server
> _without_ nscd. If you install nscd I couldn't measure a difference. I
> think we shouldn't redesign caching if there is already a caching
Thanks, according to the changelog this patch is in HEAD already (did
not check 1.0.x). So the issue is just the default for the configure
switch (or I guess if we change to default to no cache, arguably we
should just nuke all this code).
I don't think it's only LDAP - it's far too slow with /etc/passwd also I
think, without nscd.
How does the nscd caching work I wonder - remember on *every* message we
can do things like get the groups a user is in. So we need that info
in-process. Does libc keep a client-side/in-process cache also when
Is there some way to ask libc "is nscd being used"?
We probably discussed all this already and I just don't remember ;-)
Anyway, Simon I would say resolving this is not something to block on
since there's no regression, though I would still like to resolve this.
More information about the dbus