Date: Mon, 03 Oct 2016 02:15:33 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 213167] databases/db5 "Berkeley DB library configured to support only private environments" Message-ID: <bug-213167-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213167 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@FreeBSD.org Reporter: vivek@khera.org Assignee: mandree@FreeBSD.org Flags: maintainer-feedback?(mandree@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 t= he 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 sys= tem 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=20 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 on= ly 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.htm= l> 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 c= ause segfaults, and turning it on makes it useless in a multiprocessing context. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213167-13>