Hi, Axel Beckert wrote: > > > > > --On Thursday, February 07, 2013 7:45 PM +0100 Bálint Réczey > > > > > <bal...@balintreczey.hu> wrote: > > > > >> Upstream (Howard Chu, thanks!) has committed and alternate fix [1] > > > > >> [2]. > > > > >> Please consider back-porting it to Debian instead of using my patch.
This is from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038#69 -- I used the patch mentioned in there via quilt and build the package in a pbuilder Sid chroot: $ debdiff openldap_2.4.31-1.dsc openldap_2.4.31-2~abetest1.dsc diff -u openldap-2.4.31/debian/changelog openldap-2.4.31/debian/changelog --- openldap-2.4.31/debian/changelog +++ openldap-2.4.31/debian/changelog @@ -1,3 +1,9 @@ +openldap (2.4.31-2~abetest1) unstable; urgency=low + + * Testing fix for #673038 + + -- Axel Beckert <a...@debian.org> Tue, 16 Apr 2013 21:25:13 +0200 + openldap (2.4.31-1) unstable; urgency=low * New upstream release. diff -u openldap-2.4.31/debian/patches/series openldap-2.4.31/debian/patches/series --- openldap-2.4.31/debian/patches/series +++ openldap-2.4.31/debian/patches/series @@ -21,0 +22 @@ +slapcat-673038 only in patch2: unchanged: --- openldap-2.4.31.orig/debian/patches/slapcat-673038 +++ openldap-2.4.31/debian/patches/slapcat-673038 @@ -0,0 +1,21 @@ +X-Git-Url: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blobdiff_plain;f=servers%2Fslapd%2Fback-bdb%2Finit.c;h=57690fc532a3c3c803ceeb1b404ad5952b5df734;hp=1d8527332a956d4c4122ae94a69f07ba9f4da9a1;hb=HEAD;hpb=1c99711ede25860b24750aab9c529a49c53756ae + +diff --git a/servers/slapd/back-bdb/init.c b/servers/slapd/back-bdb/init.c +index 1d85273..57690fc 100644 +--- a/servers/slapd/back-bdb/init.c ++++ b/servers/slapd/back-bdb/init.c +@@ -529,7 +529,13 @@ shm_retry: + } + + if ( !quick ) { +- TXN_BEGIN(bdb->bi_dbenv, NULL, &bdb->bi_cache.c_txn, DB_READ_COMMITTED | DB_TXN_NOWAIT); ++ int txflag = DB_READ_COMMITTED; ++ /* avoid deadlocks in server; tools should ++ * wait since they have no deadlock retry mechanism. ++ */ ++ if ( slapMode & SLAP_SERVER_MODE ) ++ txflag |= DB_TXN_NOWAIT; ++ TXN_BEGIN(bdb->bi_dbenv, NULL, &bdb->bi_cache.c_txn, txflag); + } + + entry_prealloc( bdb->bi_cache.c_maxsize ); > I will try, but I can't promise that I'm able to reproduce the issue > with just artificial load. That was surprisingly easy. Additionally needed packages for my test setup: ldapvi and makepasswd. I installed slapd from Wheezy, set a password and added one additional entry (see below) using ldapvi. Due to http://bugs.debian.org/550843 I had to dump the following "editor" into a script: ---begin ldapvi-editor.sh--- #!/bin/sh sed -e 's/userPassword: .*/userPassword: '`makepasswd`'/' -i "$2" ---end ldapvi-editor.sh--- The initial slapd content looked like this: ---begin slapcat output--- dn: dc=ethz,dc=ch objectClass: top objectClass: dcObject objectClass: organization o: ethz.ch dc: ethz structuralObjectClass: organization entryUUID: c1f21214-3b12-1032-9c28-b763fe97c760 creatorsName: cn=admin,dc=ethz,dc=ch createTimestamp: 20130416185405Z entryCSN: 20130416185405.984971Z#000000#000#000000 modifiersName: cn=admin,dc=ethz,dc=ch modifyTimestamp: 20130416185405Z dn: cn=admin,dc=ethz,dc=ch objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: <admin password encoded> structuralObjectClass: organizationalRole entryUUID: c1fe26bc-3b12-1032-9c29-b763fe97c760 creatorsName: cn=admin,dc=ethz,dc=ch createTimestamp: 20130416185406Z entryCSN: 20130416185406.064157Z#000000#000#000000 modifiersName: cn=admin,dc=ethz,dc=ch modifyTimestamp: 20130416185406Z dn: cn=test,dc=ethz,dc=ch objectClass: simpleSecurityObject objectClass: organizationalRole cn: test description: #673038 test object structuralObjectClass: organizationalRole entryUUID: 8b242f46-3b13-1032-9176-ad0e06c74528 creatorsName: cn=admin,dc=ethz,dc=ch createTimestamp: 20130416185943Z userPassword:: akhzcFVvWTNzTg== entryCSN: 20130416211030.076749Z#000000#000#000000 modifiersName: cn=admin,dc=ethz,dc=ch modifyTimestamp: 20130416211030Z ---end slapcat output--- Then I started the following onliner in a root shell: # while :; do slapcat | wc -l; done It writes out a lot of "42". (Yay! The answer to life, the universe and everything! ;-) Then I started on a user shell the following oneliner: $ while :; do env EDITOR=./ldapvi-editor.sh ldapvi --noquestions -h localhost -D cn=admin,dc=ethz,dc=ch -w '<admin password>' -v -b dc=ethz,dc=ch cn=test; done This updates the user password of cn=test,dc=ethz,dc=ch on every cycle, i.e. does more or less constantly write accesses to the LDAP database. With the current package version in Wheezy/Sid, occassionally (guessed average around every 30th time) the printed number of the slapcat loop wasn't "42" but "0" or, very seldom, also numbers between 0 and 42. (I e.g. once saw a "14".) With the package build with the above patch I always had "42" and no more other numbers. For me, this confirms that the patch from http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blobdiff;f=servers/slapd/back-bdb/init.c;h=57690fc532a3c3c803ceeb1b404ad5952b5df734;hp=1d8527332a956d4c4122ae94a69f07ba9f4da9a1;hb=HEAD;hpb=1c99711ede25860b24750aab9c529a49c53756ae indeed solves the issue. The build time test suite of the package ran through successfully. There was only one issue I encountered while running this test: When running my test with the Wheezy version, I first Ctrl-C'ed the slapcat loop. This made the ldapvi loop to hang (but not abort). I Ctrl-Z'ed the ldapvi loop and "kill %1"'ed it. After that "service slapd stop" always failed. I wasn't able to "kill -TERM" slapd, I had to "kill -KILL" it. After that the package upgrade went fine and slapd successfully recovered the unclean shutdown. HTH. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
