(ITS#5250) CVSWeb log file issue
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: NA
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (38.104.138.6)
The log for the file is not complete when viewed via cvsweb. This is easily
apparent when looking at the changes for doc/man/man5/slapd.conf.5, as it is
missing recent commits.
--Quanah
15 years, 9 months
Re: (ITS#5249) OpenLDAP memory leak
by hyc＠symas.com
sumith.narayanan(a)gmail.com wrote:
> Full_Name: Sumith Narayanan
> Version: 2.3.27
> OS: MacOSX 10.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (17.216.21.198)
There are two known memory leaks related to syncrepl and one related to ACL
sets in 2.3.x releases since 2.3.27. Your 2.3.27 is quite old, the current 2.3
is 2.3.39.
There are no known leaks related to the loglevel though. That sounds more like
a memory leak in your platform's C library, in the syslog() function. You
would need to use a malloc debugger to verify that.
> My openLDAP DB is divided into 3 physical DBs, each of 4 GB , 12 GB and 26 GB
> sizes , 42 GB total.
>
> We were running with ldbm backend till 6-7 months back when the total size of
> the DB was below 30 GB. It started crashing once in a while as the size started
> increasing.
>
> We then changed the backend to Berkeley DB (Version:4.4.20) and the openLDAP
> version 2.3.27. It is running in a 8 GB memory machine with 32 bit processing
> and receives updates through an custom interface which binds to ldap and do the
> update / inserts and deletes.
>
> The rate at which the updates/inserts/deletes come is around 1-2 K / hr.
>
> Now when I start the slapd process in loglevel 256 or 512 , it starts crashing
> with in a few hours running out of memory. The maximum memory that 32 bit
> processor can use is around 2 GB. It crashes after that. I was trying to tune
> the DB_CONFIG :
>
> DB_CONFIG settings for each DB :
>
> For 26 GB DB.
> set_cachesize 0 42428800 0
> # Transaction Log settings
> set_lg_regionmax 1048576
> set_lg_max 20485760
> set_lg_bsize 2097152
>
> For 12GB DB
> set_cachesize 0 15485760 0
> set_lg_regionmax 1048576
> set_lg_max 20485760
> set_lg_bsize 2097152
>
> for 4 GB DB
> set_cachesize 0 10485760 0
> set_lg_regionmax 1048576
> set_lg_max 10485760
> set_lg_bsize 2097152
>
>
> Slapd.conf settings :
>
> loglevel 16
> gentlehup on
> idletimeout 300
> sizelimit 1000
> timelimit 300
> password-hash {SSHA}
> allow bind_v2
> threads 32
>
> These parameters are set same for all the three DBs :
>
> dbcachesize 100000
> cachesize 100000
>
> There is a replica also which gets updates from the master.
>
> Now when I change the loglevel to 32 or 16 , the process lives longer ,
> sometimes for a week or for more than a month.... However , as soon as I switch
> back to old loglevel , it starts crashing. This is happening in both master and
> slave.
>
> Could you please advice whether there is a fix for this in the current version
> or is it getting fixed in the coming version OR is it something that I can fix
> by configuring. Logs are important for us as we need to know where the requests
> are coming from. Also , the DB is accessed 250 K times in a day approximately.
>
> Please let me know if I need to furnish any more details.
>
> Thanks, Sumith.
>
>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 9 months
(ITS#5249) OpenLDAP memory leak
by sumith.narayanan＠gmail.com
Full_Name: Sumith Narayanan
Version: 2.3.27
OS: MacOSX 10.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (17.216.21.198)
My openLDAP DB is divided into 3 physical DBs, each of 4 GB , 12 GB and 26 GB
sizes , 42 GB total.
We were running with ldbm backend till 6-7 months back when the total size of
the DB was below 30 GB. It started crashing once in a while as the size started
increasing.
We then changed the backend to Berkeley DB (Version:4.4.20) and the openLDAP
version 2.3.27. It is running in a 8 GB memory machine with 32 bit processing
and receives updates through an custom interface which binds to ldap and do the
update / inserts and deletes.
The rate at which the updates/inserts/deletes come is around 1-2 K / hr.
Now when I start the slapd process in loglevel 256 or 512 , it starts crashing
with in a few hours running out of memory. The maximum memory that 32 bit
processor can use is around 2 GB. It crashes after that. I was trying to tune
the DB_CONFIG :
DB_CONFIG settings for each DB :
For 26 GB DB.
set_cachesize 0 42428800 0
# Transaction Log settings
set_lg_regionmax 1048576
set_lg_max 20485760
set_lg_bsize 2097152
For 12GB DB
set_cachesize 0 15485760 0
set_lg_regionmax 1048576
set_lg_max 20485760
set_lg_bsize 2097152
for 4 GB DB
set_cachesize 0 10485760 0
set_lg_regionmax 1048576
set_lg_max 10485760
set_lg_bsize 2097152
Slapd.conf settings :
loglevel 16
gentlehup on
idletimeout 300
sizelimit 1000
timelimit 300
password-hash {SSHA}
allow bind_v2
threads 32
These parameters are set same for all the three DBs :
dbcachesize 100000
cachesize 100000
There is a replica also which gets updates from the master.
Now when I change the loglevel to 32 or 16 , the process lives longer ,
sometimes for a week or for more than a month.... However , as soon as I switch
back to old loglevel , it starts crashing. This is happening in both master and
slave.
Could you please advice whether there is a fix for this in the current version
or is it getting fixed in the coming version OR is it something that I can fix
by configuring. Logs are important for us as we need to know where the requests
are coming from. Also , the DB is accessed 250 K times in a day approximately.
Please let me know if I need to furnish any more details.
Thanks, Sumith.
15 years, 9 months
Re: (ITS#4008) [JLDAP] LDAPConnection class does not handle null LDAPSearchQueue and LDAPSearchConstraints in search method
by rarpit＠novell.com
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=__PartD3F5D4E2.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
I tried to replicate the above problem using the following code snippet=20
=20
..........
...........
LDAPSearchQueue queue =3Dlc.search(searchBase,searchScope,searchFilter,null=
,false,null,null);
..............
..............
=20
But I am not able to find a NullPointerException as stated in the bug . It =
is working fine for me .
Please use the latest Jldap code and do let me know if I need to do =
something more to replicate the problem .=20
--=__PartD3F5D4E2.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI">
<DIV>I tried to replicate the above problem using the following code =
snippet </DIV>
<DIV> </DIV>
<DIV>..........</DIV>
<DIV>...........</DIV>
<DIV>LDAPSearchQueue queue =3Dlc.search(searchBase,searchScope,searchFilter=
,null,false,null,null);</DIV>
<DIV>..............</DIV>
<DIV>..............</DIV>
<DIV> </DIV>
<DIV>But I am not able to find a NullPointerException as stated =
in the bug . It is working fine for me .</DIV>
<DIV>Please use the latest Jldap code and do let me know if I need to do =
something more to replicate the problem . </DIV></BODY></HTML>
--=__PartD3F5D4E2.1__=--
15 years, 9 months
Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
by rarpit＠novell.com
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=__Part5C7A5B2F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Generally, the extensions (extended operations) are not common to all the =
LDAP servers. Most of the extensions available here as part of jldap(includ=
ing the GetBindDN) are exensions supported by eDirectory. However one =
should not get such exceptions, which you've reported even on the other =
LDAP servers (as Active Directory).=20
=20
However, I tried the same code as stated on AD server and I didn't get the =
exception you got. Instead I am getting the following exceptions=20
=20
Login succeeded=20
Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: =
Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown =
extended request OID, data 0, vece=20
=20
which is the expected behavior.
=20
Please check the issues once again with the latest JLDAP code and please =
do let me know if I need to do something more for replicating the problem, =
if it still persists.
--=__Part5C7A5B2F.0__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI">
<DIV>Generally, the extensions (extended operations) are not common to all =
the LDAP servers. Most of the extensions available here as part of =
jldap(including the GetBindDN) are exensions supported by eDirectory. =
However one should not get such exceptions, which you've reported even on =
the other LDAP servers (as Active Directory). </DIV>
<DIV> </DIV>
<DIV>However, I tried the same code as stated on AD server and I didn't =
get the exception you got. Instead I am getting the following exceptions =
</DIV>
<DIV> </DIV>
<DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol =
ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, =
comment: Unknown extended request OID, data 0, vece </DIV>
<DIV> </DIV>
<DIV>which is the expected behavior.</DIV>
<DIV> </DIV>
<DIV>Please check the issues once again with the latest JLDAP code and =
please do let me know if I need to do something more for replicating the =
problem, if it still persists.</DIV></BODY></HTML>
--=__Part5C7A5B2F.0__=--
15 years, 9 months
Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
by rarpit＠novell.com
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=__Part6A4C6D19.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Generally, the extensions (extended operations) are not common to all the =
LDAP servers. Most of the extensions available here as part of jldap(includ=
ing the GetBindDN) are exensions supported by eDirectory. However one =
should not get such exceptions, which you've reported even on the other =
LDAP servers (as Active Directory).=20
=20
However, I tried the same code as stated on AD server and I didn't get the =
exception you got. Instead I am getting the following exceptions=20
=20
Login succeeded=20
Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: =
Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown =
extended request OID, data 0, vece=20
=20
which is the expected behavior.
=20
Please check the issues once again with the latest JLDAP code and please =
do let me know if I need to do something more for replicating the problem, =
it it still persists.
--=__Part6A4C6D19.0__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI">
<DIV>Generally, the extensions (extended operations) are not common to all =
the LDAP servers. Most of the extensions available here as part of =
jldap(including the GetBindDN) are exensions supported by eDirectory. =
However one should not get such exceptions, which you've reported even on =
the other LDAP servers (as Active Directory). </DIV>
<DIV> </DIV>
<DIV>However, I tried the same code as stated on AD server and I didn't =
get the exception you got. Instead I am getting the following exceptions =
</DIV>
<DIV> </DIV>
<DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol =
ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, =
comment: Unknown extended request OID, data 0, vece </DIV>
<DIV> </DIV>
<DIV>which is the expected behavior.</DIV>
<DIV> </DIV>
<DIV>Please check the issues once again with the latest JLDAP code and =
please do let me know if I need to do something more for replicating the =
problem, it it still persists.</DIV></BODY></HTML>
--=__Part6A4C6D19.0__=--
15 years, 9 months
(ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS:
URL:
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Some non-atomic variables are used both outside and inside signal handlers:
clients/tools/common.c:
static int gotintr;
static int abcan;
servers/slapd/daemon.c:
static volatile int waking;
(used via WAKE_LISTENER in signal handler)
slapd/slapcat.c:
static int gotsig;
They need to be volatile sig_atomic_t.
That can be signed or unsigned char, so abcan must be set to some
#define in range 0..127 instead of -1.
Two more problems:
WAKE_LISTENER will not be correct anyway since it does '++waking' (not
atomic) and is called both inside and outside a signal handler.
The !NO_THREADS version is OK.
For that matter, behavior is only defined when the signal handler
_writes_ a volatile sig_atomic_t, not when it _reads_ it:
http://groups.google.no/group/comp.std.c/msg/d01196111ce93615
Dunno what the problem is, or if it is worse than variables
accessed by threads. I don't see anything to do about it either.
15 years, 9 months
(ITS#5247) ldapmodify results misleading
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: HEAD
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.21.80.71)
When ldapmodify prints "modify complete" all it has done so far is send the
request to the server. It hasn't actually read the server's reply yet. This
should be fixed so that better information is given to the end client about the
state of the modify request.
15 years, 9 months
Re: (ITS#5241) slapd crashes with "loglevel 0"
by rhafer＠suse.de
On Freitag, 23. November 2007, Ulrich.Windl(a)rz.uni-regensburg.de wrote:
> Full_Name: Ulrich Windl
> Version: 2.3.32
> OS: SLES10 SP1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (132.199.156.178)
>
>
> The version of OpenLDAP shipped with SUSE Linux Enterprise Server 10
> (SLES10) SP1, openldap2-2.3.32-0.23 crashes with a segmentation fault if
> "loglevel 0" is used. For other log levels things seem to work. The problem
> has been seen on x86_64 (segfaults are logged in syslog).
If you want to report bugs in OpenLDAP through the OpenLDAP ITS you should
always test if the bug is present in most recently release version of the
software (2.3.39 in this case).
If you want to report bugs against older Versions, that were shipped with a
product of some vendor you should report the bug to the vendor of that
product. So in your case please either test with OpenLDAP 2.3.39 (you can
find SLES packages here:
http://download.opensuse.org/repositories/OpenLDAP/SLE_10/
Or report the bug to SUSE/Novell here:
http://support.novell.com/additional/bugreport.html
or, if you have a valid support contract to you contact in support.
Btw, I have some x86_64 SLES10-SP1 systems with openldap-2.3.32 running here
with 'loglevel 0' without any problem, so I suspect there are some additional
things that trigger your problem. But to go further please choose one of the
options I gave you above
--
Ralf
--------------------------------------------------------------------------
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
15 years, 9 months
Re: (ITS#5245) auditlog man page and feature request
by ghenry＠suretecsystems.com
<quote who="hyc(a)symas.com">
> ghenry(a)OpenLDAP.org wrote:
>> Full_Name: Gavin Henry
>> Version: 2.4.6
>> OS: F8
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (212.159.59.85)
>>
>>
>> Note to self about man page missing any cn=config examples, for example:
>>
>> dn: cn=module{0},cn=config
>> changetype: modify
>> add: olcModuleLoad
>> olcModuleLoad: {2}auditlog.la
>>
>> dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config
>> changetype: add
>> objectClass: olcOverlayConfig
>> objectClass: olcAuditLogConfig
>> olcOverlay: auditlog
>>
>> dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config
>> changetype: modify
>> add: olcAuditlogFile
>> olcAuditlogFile: /tmp/auditlog.ldif
>>
>
> The above is a poor example, you should set all the relevant attributes
> when
> the object is created. Doing a subsequent modify is a waste.
This was just a quick c&p I did from test050, but yes, a waste.
>
>> Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp
>
> The doc says it's a fully qualified path. That means it is not a URL. This
> point is superfluous.
Aye, it will be obvious in the example.
Thanks.
>
>> Feature request:
>>
>> New config setting to define mode. At the moment it's 0644
>>
>> Thanks.
>
> --
> -- Howard Chu
> Chief Architect, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
>
15 years, 9 months
