[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [Bulk] Re: LDAP Process "hangs"

To: Andreas Gorhan <andigorhan@yahoo.de>
Subject: Re: [Bulk] Re: LDAP Process "hangs"
From: Pierangelo Masarati <masarati@aero.polimi.it>
Date: Fri, 31 Jul 2009 15:28:20 +0200
Cc: openldap-software@openldap.org, Aaron Richton <richton@nbcs.rutgers.edu>
In-reply-to: <A05A0D3D-0D08-4254-96AE-9075E88EDD63@yahoo.de>
References: <2089.8737.qm@web24714.mail.ird.yahoo.com> <Pine.SOC.4.64.0907281142390.6434@toolbox.rutgers.edu> <A05A0D3D-0D08-4254-96AE-9075E88EDD63@yahoo.de>
User-agent: Thunderbird 2.0.0.19 (X11/20090107)

Andreas Gorhan wrote:

Thanks for your reply Aaron. Seems to be a log problem. The log levelwas very high (16800) and that slows down the ldapsearch process. Anywaythanks for the answer.

This loglevel is nonsense. The mere notion of "high" makes no sense inOpenLDAP's logging configuration. The loglevel is a mask that tellswhat susbsystems are logging. 16800 means 0x41a0 which means:


sync (0x4000)
stats (0x100)
acl (0x80)
filter (0x20)

While stats definitely makes sense, and sync may make some sense whentracking synchronization issues that can only be tracked "live", acl andfilter do not make any sense in a production environment. Acl onlymakes sense in extreme cases while debugging acl design. Similarconsiderations apply to filter.

p.

References:
- LDAP Process "hangs"
  - From: Andi Gorhan <andigorhan@yahoo.de>
- Re: LDAP Process "hangs"
  - From: Aaron Richton <richton@nbcs.rutgers.edu>
- Re: [Bulk] Re: LDAP Process "hangs"
  - From: Andreas Gorhan <andigorhan@yahoo.de>

Prev by Date: Re: BT IP Exchange interconnect
Next by Date: Stability of autogroup overlay with OpenLDAP < 2.4.18
Index(es):
- Chronological
- Thread