[Bug 213167] databases/db5 "Berkeley DB library configured to support only private environments"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213167

            Bug ID: 213167
           Summary: databases/db5 "Berkeley DB library configured to
                    support only private environments"
           Product: Ports & Packages
           Version: Latest
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: mandree at FreeBSD.org
          Reporter: vivek at khera.org
          Assignee: mandree at FreeBSD.org
             Flags: maintainer-feedback?(mandree at FreeBSD.org)

Berkeley DB5 (likely other versions as well) running on FreeBSD/arm 11.0 on a
Raspberry Pi 2 issues the error

 BDB1577 Berkeley DB library configured to support only private environments

for many operations.

Specifically I'm using it with netatalk3 having everything installed from the
official pkg repository. When netatalk tries to open a share, it needs to
create a DB file to store the necessary mapping data. It always fails, and the
db_errlog file is full of the above error message. Causing netatalk3 to use one
of its fallback in-memory storage systems, one can connect to the files system
using a Mac quite well. However, this is not a recommended configuration.

The error can also be emitted by going to a directory with a DB file in it, and
running 

 db_checkpoint-5.3 -1 -h .


This seems related to the --enable-posixmutexes option that is turned on for
the arm build of the db5 port as per bug #197227

According to the DB5 manual for this option: "...configuring to use POSIX
mutexes when the implementation does not have inter-process support will only
allow the creation of private database environments". It appears that
FreeBSD/arm 11.0 does not implement multi process mutexes still.

There are other projects that also need to have shared mutexes working and this
has been discussed occasionally since FreeBSD 9 at least. For example,
sphinxsearch as per
<https://lists.freebsd.org/pipermail/freebsd-questions/2012-June/242870.html>
which also references a discussion from two years prior
<http://freebsd.1045724.x6.nabble.com/What-is-the-status-of-thread-process-shared-synchronization-td4224458.html>
which seems to not have a real conclusion.

What's the solution here? Turning off the posixthreads seems like it will cause
segfaults, and turning it on makes it useless in a multiprocessing context.

-- 
You are receiving this mail because:
You are the assignee for the bug.