https://bugs.openldap.org/show_bug.cgi?id=8255
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.7.0 |2.6.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9661
Issue ID: 9661
Summary: How to monitor an LDMB file for being pretty full
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
https://ltb-project.org/documentation/nagios-plugins/check_lmdb_usage provides
a Nagios plugin, to check how full/free a LMDB database is. It calls mbd_stat
-ef, and parses from the output the numbers in the “Max pages:”, “Number of
pages used:”, and “Free pages:” lines.
With these numbers it calculates “the percent of used pages” or “the percent of
free pages” and signals the status with return values 0 -OK, 1 - warning, or 2
- critical . The disadvantage of check_lmdb_usage is, that it requires perl.
Do you recommend to monitor the absolute number of free pages, the relative
number of free pages, the absolute number of used pager, or the relative number
of used pages?
Please extend mdb_stat to be suitable for monitoring the fullness of a LMDB
directory - accept parameters of for a warning and critical threshold, and a
parameter on how to calculate the criterion (A - based on absolute number of
free pages, B - relative number of free pages, C - absolute number of used
pages, or D - relative number of used pages).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8375
--- Comment #7 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> ---
I can reproduce it on any sufficiently large db, both tree-structured or flat,
given the right search scope.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8375
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs_review
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
I'll put needs review on it though so we can discuss. ;)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8375
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to geert.hendrickx(a)telenetgroup.be from comment #4)
> Hi
>
> I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly
> slapadd'ed mdb.
Target milestone for the fix is 2.7.0, so that's expected. ;)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8375
--- Comment #4 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> ---
Hi
I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly
slapadd'ed mdb.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9658
Issue ID: 9658
Summary: libldap fails to compile on Hurd: MAXPATHLEN
undeclared
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
OpenLDAP 2.5 and later fails to compile on GNU/Hurd:
libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c
request.c -fPIC -DPIC -o .libs/request.o
In file included from ldap-int.h:119,
from request.c:53:
request.c: In function 'ldap_dump_connection':
../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in
this function)
181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH="))
| ^~~~~~~~~~
request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN'
859 | char from[LDAP_IPADDRLEN];
| ^~~~~~~~~~~~~~
../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported
only once for each function it appears in
181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH="))
| ^~~~~~~~~~
request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN'
859 | char from[LDAP_IPADDRLEN];
| ^~~~~~~~~~~~~~
Makefile:435: recipe for target 'request.lo' failed
make[2]: *** [request.lo] Error 1
This is not the same as ITS#9648. I have pulled latest master and the patch for
that one does not solve it.
GNU/Hurd actually does not have a MAXPATHLEN constant at all; paths are
expected to be dynamically allocated. See:
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_…
This is a low priority issue for me personally. I'm just filing it for
tracking. I'm hoping someone from the GNU/Hurd community might be able to work
on a patch.
--
You are receiving this mail because:
You are on the CC list for the issue.