On Tuesday 26 April 2005 11:36, you wrote:
> On Mon, Apr 25, 2005 at 11:58:56AM +0200, Marcus Hardt wrote:
>
> ...
>
> > Apr 22 19:20:02 xen-4-1 slapadd: ldbm: ==> unable to initialize mutex:
> > Function not implemented
> > Apr 22 19:20:02 xen-4-1 slapadd: ldbm: ==> process-private: unable to
> > initialize environment lock: Function not implemented
> > Apr 22 19:20:02 xen-4-1 slapadd: ldbm_initialize_env(): FATAL error in
> > dbEnv->open() : Function not implemented (38)
> >
> > These syslog entries do not appear when moving /lib/tls.disabled.for.xen
> > to /lib/tls.
> > Unfortunately I cannot make sure if things work then, because my setup
> > seems to be
> > infunctional yet.
>
> IMHO this is caused because db4 has a depndency on nptl!
> Have a look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933
> for details on the problem.
>
> The fedora rpms are fine AFAIK so you can backport changes from there.
>
> > However, the xen people do not suggest using /lib/tls, because it brings
> > instabilities
> > as well as performance problems.
> >
> > Is it necessary to use ldbm?
>
> I don't see why, ldbm is popular lately because of better performance
> but any backend should do.
>
> > Is there any other way out?
>
> Get a db4 version that doesn't depend on NPTL ;P
It turned out that the slap provided by the plain SL rpm does not use DB4 and
thus works fine.
Thanks you very much!
Marcus.
> Cheers,
> Kostas
>
> PS> I haven't tried xen with a RHEL3 yet but i suspect you'll have similar
> problems with other libraries that depend on NPTL (newer versions of java
> come to mind).
--
Marcus
|