Re: (ITS#4713) test030-relay broken in HEAD
by ando＠sys-net.it
quanah(a)stanford.edu wrote:
> When running test030-relay, I get a failure.
>
works just fine here, on Linux 32 bit and Solaris 64 bit
> Basic output shows:
>
> Using meta backend...
>
> Starting slapd on TCP/IP port 9011...
> Using ldapsearch to check that slapd is running...
> Using ldapadd to populate the database...
> Searching base="dc=example,dc=com"...
> Searching base="o=Example,c=US"...
> Search failed (255)!
> ./scripts/test030-relay: line 79: kill: (20796) - No such process
>
Sounds like slapd either stopped or crashed; anything relevant from
slapd's logs (or any core dump around)?
> The ldapsearch.out file shows:
>
snip...
> # searching base="o=Example,c=US"...
> ldap_result: Can't contact LDAP server (-1)
>
This is not much indicative of the reason of the failure; see above.
Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which
I only noticed and fixed late Sunday 15; please make sure you're using
the correct files from HEAD.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 11 months
(ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu
Full_Name: Quanah Gibson-Mount
Version: HEAD 2006/10/15
OS: Linux 2.6 64-bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)
When running test030-relay, I get a failure.
Basic output shows:
Using meta backend...
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Using ldapadd to populate the database...
Searching base="dc=example,dc=com"...
Searching base="o=Example,c=US"...
Search failed (255)!
./scripts/test030-relay: line 79: kill: (20796) - No such process
The ldapsearch.out file shows:
objectClass: OpenLDAPperson
cn: Ursula Hampster
sn: Hampster
uid: uham
title: Secretary, UM Alumni Association
postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109
seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com
homePostalAddress: 123 Anystreet $ Anytown, MI 48104
mail: uham(a)mail.alumni.example.com
homePhone: +1 313 555 8421
pager: +1 313 555 2844
facsimileTelephoneNumber: +1 313 555 9700
telephoneNumber: +1 313 555 5331
# searching base="o=Example,c=US"...
ldap_result: Can't contact LDAP server (-1)
16 years, 11 months
Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com
Pierangelo Masarati wrote:
> Michael Ströder wrote:
>
>> Yes, I learned this (again) on Friday. ;-)
>>
>> export CFLAGS="-g"
>
> Note that this does not disable optimization (AFAIK); I'd place an
> explicit CFLAGS="-g -O0".
Unfortunately this does not help.
>> But it still does not work.
>>
> But in any case that doesn't seem to be the issue. What gcc are you
> using?
SuSE Linux 10.1
$ gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp
--disable-libssp --enable-java-awt=gtk --enable-gtk-cairo
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--without-system-libunwind --with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.0 (SUSE Linux)
Ciao, Michael.
16 years, 11 months
Re: (ITS#4712) test007: slapd crashes
by quanah＠stanford.edu
--On Sunday, October 15, 2006 10:08 PM +0000 hyc(a)symas.com wrote:
> ando(a)sys-net.it wrote:
>> Michael Str?der wrote:
>>> Yes, I learned this (again) on Friday. ;-)
>>>
>>> export CFLAGS="-g"
>>>
>> Note that this does not disable optimization (AFAIK); I'd place an
>> explicit CFLAGS="-g -O0".
>
> No, the default without any -O flag is no optimization.
>
>>> But it still does not work.
>>>
>> But in any case that doesn't seem to be the issue. What gcc are you
>> using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red
>> Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note
>> that I don't assume this could have an impact on your issue.
>
> I think Michael just has a corrupt build tree. The previous issue he
> reported was cleared up by running "make clean" in the back-bdb and
> back-monitor directories, then rebuilding. I suspect just doing a "make
> clean" from the top level and rebuilding would clear up the rest.
HEAD from today builds just fine for me, with BDB 4.5, and test007 passes.
OL 2.3.27 doesn't work with BDB 4.5, although I (so far) have not been able
to track down a BDB 4.5 specific commit to HEAD.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
16 years, 11 months
Re: (ITS#4712) test007: slapd crashes
by hyc＠symas.com
ando(a)sys-net.it wrote:
> Michael Ströder wrote:
>> Yes, I learned this (again) on Friday. ;-)
>>
>> export CFLAGS="-g"
>>
> Note that this does not disable optimization (AFAIK); I'd place an
> explicit CFLAGS="-g -O0".
No, the default without any -O flag is no optimization.
>> But it still does not work.
>>
> But in any case that doesn't seem to be the issue. What gcc are you
> using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red
> Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note
> that I don't assume this could have an impact on your issue.
I think Michael just has a corrupt build tree. The previous issue he
reported was cleared up by running "make clean" in the back-bdb and
back-monitor directories, then rebuilding. I suspect just doing a "make
clean" from the top level and rebuilding would clear up the rest.
This does point out a bug in the slapd Makefile; for dynamic backends it
appears to not remake the backend directories if they have already been
built once. I'll look into that...
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 11 months
Re: (ITS#4712) test007: slapd crashes
by ando＠sys-net.it
Michael Ströder wrote:
> Yes, I learned this (again) on Friday. ;-)
>
> export CFLAGS="-g"
>
Note that this does not disable optimization (AFAIK); I'd place an
explicit CFLAGS="-g -O0".
> But it still does not work.
>
But in any case that doesn't seem to be the issue. What gcc are you
using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red
Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note
that I don't assume this could have an impact on your issue.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 11 months
Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com
Pierangelo Masarati wrote:
>
> this backtrace looks weird, because:
> - bconfig.c:2734 is not in config_replica() in HEAD right now, and,
> according to cvsweb, the last commit to bconfig.c occurred 4 weeks ago
> (unless you modified that file yourself)
The only modifications to my HEAD source tree are
happening through cvs up -RdP .
> You should really cross-check what you're debugging, or something else
> is going berserk. Maybe try without optimization?
Yes, I learned this (again) on Friday. ;-)
export CFLAGS="-g"
But it still does not work.
Ciao, Michael.
16 years, 11 months
Re: (ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it
> > slapcat -f slapd.conf
>
>
> So you understand that without the -l flag to slapcat, you are
> writing to
> stdout instead of a file? Is it possible that is what is causing
> slapcat
> to crash?
>
I used slapcat without -l for two reasons:
usually i slapcat pipiing in gzip the stdout so i can realtime gzip
the ldif:
slapcat -f slapd.conf | gzip > out.ldif.gz
and also because on 32 bit slapcat, avoid the 2GB filsize limit on
output ldif
> > slapcat -f slapd.conf
here the full command was:
slapcat -f slapd.conf > fulldump.ldif
However, I've retry with "-l file" on 32 bit linux and solaris (why
not ?)
Linux stops when reached 2GB file out; but there was a little bit of
memory available and the allocation rate was similar to previous trials
In Solaris, due to speed up the test I've ulimit -d 1024000, reached
2 GB file without stops itself (usually solaris continues, simply
throws out additional data)
then some time later:
ch_malloc of 16392 bytes failed
ch_malloc.c:57: failed assertion `0'
Abort (core dumped)
with a while/loop ps, last line was:
PID RSS VSZ %MEM TIME STIME COMMAND
18246 1652488 1656144 41.1 31:23 09:22:35 slapcat
> On my linux 2.6 system (64 bit), with a 2.5 million entry db, which
> is:
>
> ldap00:/var/lib/ldap/slamd/64-2.5mil-db42# du -h *.bdb
> 84M cn.bdb
> 618M dn2id.bdb
> 85M employeeNumber.bdb
> 3.2G id2entry.bdb
> 3.7M objectClass.bdb
> 85M uid.bdb
this runs I've tried a db like:
ldap@labsLDAP:/TEST_producer/openldap-data> du -h *.bdb
3,0M testCode.bdb
2,9G dn2id.bdb
600M entryCSN.bdb
545M entryUUID.bdb
15G id2entry.bdb
1,9M objectClass.bdb
270M testId.bdb
> So, that does mean one thing -- It definitely outgrew the 366MB of BDB
> cache defined. On the other hand, once it reached its max size, it
> stayed
> steady there until completion was reached.
>
In my trials, instead, allocation never stops :(
Perhaps due to a greater DB ?
Paolo
16 years, 11 months
Re: (ITS#4709) Insufficient permissions on PF_LOCAL sockets
by ando＠sys-net.it
Applied to HEAD; please check.
Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 11 months
Re: (ITS#4709) Insufficient permissions on PF_LOCAL sockets
by ando＠sys-net.it
ian(a)uns.ns.ac.yu wrote:
> Linux, as opposed to other *NIXes, honors PF_LOCAL socket file mode bits, so a
> user must have the write permission to use the socket. OpenLDAP bind()s its
> PF_LOCAL sockets without any special arrangements, so the resulting socket's
> permissions are governed by the current umask. Since the umask is usually 022 or
> 002, the socket ends up not being world-writable, making it unusable for users
> other than root.
>
> Earlier OpenLDAP releases recognized a non-standard "x-mod" URL extension for
> manipulating socket permissions, and the parsing code is still there, but its
> results are unused.
>
Yes, that's been removed because non-portable and of little use. The
preferred use consists in creating the socket according to umask in a
directory with the desired permissions. Right now, those permissions
are used to coarse grain regulate operations on a specific listener;
considering their limited usefulness, their use is not recommended as
that extension could be removed. It's considered experimental.
> With the attached patch, PF_LOCAL sockets are always created world-writable by
> setting the umask to zero before bind(). The previous umask is restored
> immediately afterwards. Umask manipulation shouldn't affect PF_UNIX bind()s, so
> I haven't surrounded it with #ifdef LDAP_PF_LOCAL.
>
Your approach seems to be sound. I'll review the patch.
Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 11 months