Re: (ITS#4938) hdb_db_close SEGVs
by richton＠nbcs.rutgers.edu
I don't have #5 (sleepycat#14657) nor the unofficial
http://www.stanford.edu/services/directory/openldap/configuration/patches...
patch. As for the official one, I'm not sure about its relevance to the
actual SEGV due to the "recovery...fail" comment. In other words, though
it may be impacting the ability of alock/db_recover to do its thing,
that's just a side effect of the unclean shutdown which is the real bug
here to my view.
The region size patch is interesting, but I will tell you that the
database in question has
set_cachesize 0 200000000 0
and it (to a glance) looks like that only impacts the gig column, which I
have as zero anyway.
I can tell you that stop/starts weren't an issue with 2.3.32 and the same
Sleepycat binaries...not that I stop/start often as a rule of thumb. (I am
lately; we're implementing ando's {RADIUS} module.) But two identical
traces on two different boxes caught my eye.
On Thu, 26 Apr 2007, Quanah Gibson-Mount wrote:
>
> ----- richton(a)nbcs.rutgers.edu wrote:
>> Full_Name: Aaron RIchton
>> Version: 2.3.35
>> OS: Solaris 9
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (128.6.30.206)
>>
>>
>> BDB 4.2.52. I've had a couple (different) machines SEGV on slapd
>> shutdown. Both
>> had identical stack traces:
>
> Wierd, I've been running hdb on my servers for nearly a year without such an issue. Did this just start with 2.3.35?
>
> Also, what patches do you have applied to BDB 4.2.52. I'm up to 6 now.
>
> <http://www.stanford.edu/services/directory/openldap/configuration/bdb-bui...>
>
> 5 are direct from sleepycat:
>
> <http://www.oracle.com/technology/products/berkeley-db/db/update/4.2.52/pa...>
>
> with the last one there possibly impacting you if you don't have it?
>
> --Quanah
>
> --
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
16 years, 5 months
(ITS#4938) hdb_db_close SEGVs
by richton＠nbcs.rutgers.edu
Full_Name: Aaron RIchton
Version: 2.3.35
OS: Solaris 9
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.6.30.206)
BDB 4.2.52. I've had a couple (different) machines SEGV on slapd shutdown. Both
had identical stack traces:
current thread: t@1
=>[1] __dbreg_revoke_id(dbp = 0xa498818, have_lock = 0, force_id = -1), line 427
in "dbreg.c"
[2] __dbreg_close_files(dbenv = 0x405320), line 206 in "dbreg_util.c"
[3] __log_dbenv_refresh(dbenv = 0x405320), line 744 in "log.c"
[4] __dbenv_refresh(dbenv = 0x405320, orig_flags = 0, rep_check = 0), line 648
in "env_open.c"
[5] __dbenv_close(dbenv = 0x405320, rep_check = 0), line 579 in "env_open.c"
[6] __dbenv_close_pp(dbenv = 0x405320, flags = 0), line 534 in "env_open.c"
[7] hdb_db_close(be = 0x367340), line 517 in "init.c"
[8] backend_shutdown(be = 0x367340), line 351 in "backend.c"
[9] slap_shutdown(be = (nil)), line 279 in "init.c"
[10] main(argc = 4, argv = 0xffbffd6c), line 870 in "main.c"
No idea if this is Sleepycat or slapd, but it dirties the database in a way that
automatic nor command-line db_recover appreciate:
Ignoring log file: log.0000000007: magic number 0, not 40988
Invalid log file: log.0000000007: Invalid argument
PANIC: Invalid argument
PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
hdb_db_open: Database cannot be recovered, err -30978. Restore from backup!
DB_ENV->lock_id_free interface requires an environment configured for the
locking subsystem
txn_checkpoint interface requires an environment configured for the transaction
subsystem
bdb_db_close: txn_checkpoint failed: Invalid argument (22)
backend_startup_one: bi_db_open failed! (-30978)
16 years, 5 months
Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: RE23
> OS: Linux
> URL:
> Submission from: (NULL) (129.240.202.105)
> Submitted by: hallvard
>
>
> overlay chain breaks with databases ldbm and ldif:
>
> ./run -b {ldbm or ldif} test032-chain outputs:
> ...
> Starting second slapd on TCP/IP port 9012...
> ...
> Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com"
> on port 9012...
> ldapcompare failed (10)!
>
> ldapcompare output in testrun/test.out:
> Compare Result: Referral (10)
> Matched DN: ou=People,dc=example,dc=com
> Referral: ldap://localhost:9011/ou=People,dc=example,dc=com
> UNDEFINED
>
> testrun/slapd.1.log says the Compare was sent to the chained server, but
> with baseDN=<Matched DN above>:
> ...
> do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot)
> conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn"
> ...
> conn=5 op=2 RESULT tag=111 err=16 text=
> ...
>
> Slapcat says the Matched DN entry is correct (same as in a BDB run):
> dn: ou=People,dc=example,dc=com
> objectClass: referral
> objectClass: extensibleObject
> ou: People
> ref: ldap://localhost:9011/ou=People,dc=example,dc=com
> structuralObjectClass: referral
>
>
> Also the Statslog output is wrong for all three databases:
>
> With LDBM and LDIF, the CMP operation is not logged, only its result:
> grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above
> conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012)
> conn=4 op=0 BIND dn="" method=128
> conn=4 op=0 RESULT tag=97 err=0 text=
> conn=4 op=1 RESULT tag=111 err=10 text=
> conn=4 op=2 UNBIND
> conn=4 fd=14 closed
>
> With BDB, the CMP operation is not logged, but both the returned
> result and the suppressed referral result is logged:
> conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012)
> conn=4 op=0 BIND dn="" method=128
> conn=4 op=0 RESULT tag=97 err=0 text=
> conn=4 op=1 RESULT tag=111 err=6 text=
> conn=4 op=1 RESULT tag=111 err=10 text=
> conn=4 op=2 UNBIND
> conn=4 fd=12 closed
>
>
> I haven't tried other databases, but since two different databases
> had the same bug and same wrong Statlog, I'm guessing others do too.
This seems to be a known limitation, see the FIXME in slapd/compare.c,
near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem for
back-ldif, which does not provide its own compare entry point. As for
back-ldbm, there is a missing referral_rewrite call in
back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm,
but you're welcome to fix it if you wish. Just have a look at
back-bdb/referral.c for the correct code.
--
-- 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/
16 years, 5 months
(ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: RE23
OS: Linux
URL:
Submission from: (NULL) (129.240.202.105)
Submitted by: hallvard
overlay chain breaks with databases ldbm and ldif:
./run -b {ldbm or ldif} test032-chain outputs:
...
Starting second slapd on TCP/IP port 9012...
...
Comparing "cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com"
on port 9012...
ldapcompare failed (10)!
ldapcompare output in testrun/test.out:
Compare Result: Referral (10)
Matched DN: ou=People,dc=example,dc=com
Referral: ldap://localhost:9011/ou=People,dc=example,dc=com
UNDEFINED
testrun/slapd.1.log says the Compare was sent to the chained server, but
with baseDN=<Matched DN above>:
...
do_compare: dn (ou=People,dc=example,dc=com) attr (cn) value (mark elliot)
conn=5 op=2 CMP dn="ou=People,dc=example,dc=com" attr="cn"
...
conn=5 op=2 RESULT tag=111 err=16 text=
...
Slapcat says the Matched DN entry is correct (same as in a BDB run):
dn: ou=People,dc=example,dc=com
objectClass: referral
objectClass: extensibleObject
ou: People
ref: ldap://localhost:9011/ou=People,dc=example,dc=com
structuralObjectClass: referral
Also the Statslog output is wrong for all three databases:
With LDBM and LDIF, the CMP operation is not logged, only its result:
grep '^conn=4' testrun/slapd.2.log # the ldapcompare operation above
conn=4 fd=14 ACCEPT from IP=127.0.0.1:45280 (IP=127.0.0.1:9012)
conn=4 op=0 BIND dn="" method=128
conn=4 op=0 RESULT tag=97 err=0 text=
conn=4 op=1 RESULT tag=111 err=10 text=
conn=4 op=2 UNBIND
conn=4 fd=14 closed
With BDB, the CMP operation is not logged, but both the returned
result and the suppressed referral result is logged:
conn=4 fd=12 ACCEPT from IP=127.0.0.1:42190 (IP=127.0.0.1:9012)
conn=4 op=0 BIND dn="" method=128
conn=4 op=0 RESULT tag=97 err=0 text=
conn=4 op=1 RESULT tag=111 err=6 text=
conn=4 op=1 RESULT tag=111 err=10 text=
conn=4 op=2 UNBIND
conn=4 fd=12 closed
I haven't tried other databases, but since two different databases
had the same bug and same wrong Statlog, I'm guessing others do too.
16 years, 5 months
Re: (ITS#4936) default modulepath
by ahasenack＠terra.com.br
On Mon, Apr 23, 2007 at 09:17:26PM +0000, abartlet(a)samba.org wrote:
> It would be very useful if OpenLDAP would provide a default value for
> modulepath.
>
> This would ensure that on systems with multiple openldap installs (such as test
> rigs) that we do not need to specify the *correct* modulepath, when starting the
> config with different slapd binaries.
>
> Similarly, it would avoid the need to guess which modulepath is correct for a
> given system, such as when we find slapd in the path (as Samba4's test mode
> does), but needs to automatically enable modules.
Another scenario is with some tool providing a config file for slapd. It
wouldn't have to guess the host arch whether it's i386 or x86_64 and set
the correct module_path (/usr/lib/openldap vs /usr/lib64/openldap).
16 years, 5 months
(ITS#4936) default modulepath
by abartlet＠samba.org
Full_Name: Andrew Bartlett
Version: devel
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (66.70.73.150)
It would be very useful if OpenLDAP would provide a default value for
modulepath.
This would ensure that on systems with multiple openldap installs (such as test
rigs) that we do not need to specify the *correct* modulepath, when starting the
config with different slapd binaries.
Similarly, it would avoid the need to guess which modulepath is correct for a
given system, such as when we find slapd in the path (as Samba4's test mode
does), but needs to automatically enable modules.
(Discussed with Howard Chu)
16 years, 5 months
Re: (ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com
--=__PartDCFBBB68.0__=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Confirmed fix works.
— Luke
--=__PartDCFBBB68.0__=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.5346.5" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Confirmed fix works.</DIV>
<DIV> </DIV>
<DIV>=E2=80=94 Luke<BR></DIV></BODY></HTML>
--=__PartDCFBBB68.0__=--
16 years, 5 months
(ITS#4935) SASL_MAX_BUFF_SIZE is too small
by lukeh＠novell.com
Full_Name: Luke Howard
Version: 2.3.32
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (125.16.129.17)
SASL_MAX_BUFF_SIZE is too small for SASL mechanisms, such as GSS-SPNEGO, that
use a buffer size unconstrained by the 64K limit defined for some mechanisms in
RFC 2222.
A more reasonable default would 0xFFFFFF (2^24), used as the maximum buffer size
by many of the mechanisms shipped with Cyrus itself.
16 years, 5 months
(ITS#4934) Port change
by babu.suresh＠pacificlife.com
Full_Name: Babu
Version: 2.3
OS: RedHAT3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (198.181.8.254)
My openldap was running on default port 389 and imported all schema & data. Now
I would like to change the port to different..would be 4000/5000. OpenLDAP
process started successfully with non default port but I am getting "error 32 no
such object" when try to browse the data using soferra.
is it possible to change the port anytime?
thank you
16 years, 5 months
