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
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).
|