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

Re: chain-overlay question

To: openldap-software@openldap.org
Subject: Re: chain-overlay question
From: Markus Krause <krause@biochem.mpg.de>
Date: Tue, 15 May 2007 20:34:58 +0200
Content-disposition: inline
In-reply-to: <4649DA0D.6050305@sys-net.it>
References: <20070514225125.ccc0oso60wswcsss@webmail2.biochem.mpg.de> <4648D2DC.5020000@sys-net.it> <20070515011745.rxir2hp7vkgkw0ow@webmail2.biochem.mpg.de> <46495211.3040009@sys-net.it> <20070515165314.uzyfbsiuas408o8k@webmail2.biochem.mpg.de> <4649DA0D.6050305@sys-net.it>
User-agent: Internet Messaging Program (IMP) H3 (4.1.4)

Zitat von Pierangelo Masarati <ando@sys-net.it>:

Markus Krause wrote:
No. I'm referring to slapd.4.conf as generated by the test018 script.
ah ok, sorry for that. i could not find it at first, had ro stop "make test" at test018 to get it ... now i used it (and slapd.1.conf) as template for my config.
I assumed you knew that you can tun a single test by issuing
	./run test018
from the tests/ directory. Sorry about that.

ok, no problem, next time i'll use that!

i am really sorry about still bothering you with my problems but i still have no success... :-( my slapd.conf now looks like (now in more detail, just cleaned up): --- slapd.conf [...] --- end of slapd.conf
To me, it looks just fine.

good! :-) at least i got that now!

Please rearrange the configuration as instructed and retry.  In general,
never intermix database and overlay directives.  Order matters (as it
always did; but now violations are no longer harmless).
i hope i did understand how which order the entries should have ... (see above)

but the last lines before the consumer dies after running "ldappasswd .." show: --- slapd -d 65535 output ... => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000337f entry_decode: "uid=user,o=test" <= entry_decode(uid=user,o=test) ldap_url_parse_ext(ldaps://ldapprov) send_ldap_extended: err=10 oid= len=0 ldap_url_parse_ext(ldaps://ldapprov) Segmentation fault --- end of slapd -d 65535 output
That's another issue. You may send a stack backtrace after this crash.

here are the last 70 lines which i think are written by strace after i used ldappasswd (just tell me if you want to see more of it, i just thought that 2600+ lines are to much for the list and of no use): --- tail -70 strace slapd -d 65535 time(NULL) = 1179248871 time(NULL) = 1179248871 close(14) = 0 close(15) = 0 close(13) = 0 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 fcntl64(12, F_GETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024, pid=0}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 write(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 3072, SEEK_SET) = 3072 read(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 yHF\0\0\0\0\242q\0\0\0\0"..., 1024) = 1024 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 read(13, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 512) = 512 close(13) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 time(NULL) = 1179248871 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\22\0\0\0\tEQ\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 512) = 512 close(14) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 time(NULL) = 1179248871 pread64(13, "\20\0\0\0008\fY\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344?\3\3"..., 16384, 16384) = 16384 pread64(13, "\22\0\0\0:^i\0\220\3\0\0\0\0\0\0\0\0\0\0\335\0010\"\2\3"..., 16384, 14942208) = 16384 pread64(13, "\22\0\0\0\235\0m\0W\3\0\0O\3\0\0\0\0\0\0\20\0\270!\1\5"..., 16384, 14008320) = 16384 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb63c3000 time(NULL) = 1179248871 write(2, "=> bdb_entry_get: ndn: \"o=testh"..., 49) = 49 write(2, "=> bdb_entry_get: oc: \"(null)\", "..., 49) = 49 write(2, "bdb_dn2entry(\"o=test"..., 40) = 40 write(2, "=> bdb_dn2id(\"o=test"..., 40) = 40 pread64(14, "\t\0\0\0D+=\0\1\0\0\0\0\0\0\0\0\0\0\0\20\0\214\r\3\3\364"..., 4096, 4096) = 4096 pread64(14, "\n\0\0\0\212\242P\0_\2\0\0\0\0\0\0G\4\0\0G\0\364\7\2\3"..., 4096, 2486272) = 4096 pread64(14, "\22\0\0\0i\374l\0\n\0\0\0Q\3\0\0\33\4\0\0>\0\230\6\1\5"..., 4096, 40960) = 4096 write(2, "<= bdb_dn2id: got id=0x00000001\n", 32) = 32 pread64(13, "\20\0\0\0\230\313X\0\217\3\0\0\0\0\0\0\0\0\0\0\307\1\224"..., 16384, 14925824) = 16384 pread64(13, "\22\0\0\0O\2m\0\2\0\0\0\0\0\0\0\3\0\0\0(\0|\4\1\5\370?"..., 16384, 32768) = 16384 write(2, "entry_decode: \"o=test"..., 40) = 40 write(2, "<= entry_decode(o=test"..., 41) = 41 write(2, "=> bdb_entry_get: found entry: \""..., 57) = 57 write(2, "bdb_entry_get: rc=0\n", 20) = 20 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5bc2000 mprotect(0xb5bc2000, 4096, PROT_NONE) = 0 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 374 futex(0xb63c2be8, FUTEX_WAIT, 374, NULL) = 0 write(2, "slapd starting\n", 15) = 15 mmap2(NULL, 385024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5363000 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 375 futex(0xb63c2be8, FUTEX_WAIT, 375, NULL) = 0 +++ killed by SIGSEGV +++ ---

In any case, you didn't specify you were trying to perform an extended
operation (ldap passwd); there might be some bg in how extended
operations are handled by slapo-chain(5).

sorry, i thought i mentioned that the crash occurs on using "ldappasswd" via the command line ... and did not know that this is an extended operation

I'd narrow this down by running ldappasswd within a simpler configuration
setup.  In case, please file an ITS.

ok, its ID 4964: http://www.openldap.org/its/index.cgi/Incoming?id=4964;expression=slapo-chain

In the meanwhile, I'd check your configuration by using a less
challenging write operation (like a modify).


thanks again for your help!

with best regards
   markus


+-----------------------------------------------------------------+
| Markus Krause, Mogli-Soft                                       |
| Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL        |
| by order of the                                                 |
|    Computing Center of the Max-Planck-Institute of Biochemistry |
+--------------------------------+--------------------------------+
| E-Mail: krause@biochem.mpg.de  |  Tel.: 089 - 89 40 85 99       |
|         markus.krause@mac.com  |  Fax.: 089 - 89 40 85 98       |
|  Skype: markus.krause          | iChat: markus.krause@mac.com   |
+--------------------------------+--------------------------------+

----------------------------------------------------------------------
     This message was sent using https://webmail2.biochem.mpg.de
If you encounter any problems please report to rz-linux@biochem.mpg.de

Follow-Ups:
- Re: chain-overlay question
  - From: Pierangelo Masarati <ando@sys-net.it>

References:
- chain-overlay question
  - From: Markus Krause <krause@biochem.mpg.de>
- Re: chain-overlay question
  - From: Pierangelo Masarati <ando@sys-net.it>
- Re: chain-overlay question
  - From: Markus Krause <krause@biochem.mpg.de>
- Re: chain-overlay question
  - From: Pierangelo Masarati <ando@sys-net.it>
- Re: chain-overlay question
  - From: Markus Krause <krause@biochem.mpg.de>
- Re: chain-overlay question
  - From: Pierangelo Masarati <ando@sys-net.it>

Prev by Date: Re: ACL Assistance
Next by Date: Re: chain-overlay question
Index(es):
- Chronological
- Thread