Debian Bug report logs - #255276
slapd/slapcat hang in endless loops

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Hadmut Danisch <debbug2@danisch.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: slapd/slapcat hang in endless loops

Date: Sun, 20 Jun 2004 01:23:37 +0200

Package: slapd
Version: 2.1.30-1
Severity: normal

Hi,

since I've upgraded my machine to 2.6.7 slapd
(and even slapcat) hang. When tracing with strace, 
they are caught in an endless loop of 

sched_yield()                           = 0


calls.

regards
Hadmut


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-danisch-p4-intel
Locale: LANG=C, LC_CTYPE=de_DE

Versions of packages slapd depends on:
ii  coreutils [fileutils]       5.0.91-2     The GNU core utilities
ii  debconf                     1.4.25       Debian configuration management sy
ii  libc6                       2.3.2.ds1-13 GNU C Library: Shared libraries an
ii  libdb4.2                    4.2.52-16    Berkeley v4.2 Database Libraries [
ii  libgcrypt7                  1.1.90-1.1   LGPL Crypto library - runtime libr
ii  libgnutls10                 1.0.4-3      GNU TLS library - runtime library
ii  libgpg-error0               0.7-1        library for common error values an
ii  libiodbc2                   3.51.2-2     iODBC Driver Manager
ii  libldap2                    2.1.30-1     OpenLDAP libraries
ii  libltdl3                    1.5.6-1      A system independent dlopen wrappe
ii  libsasl2                    2.1.18-4.1   Authentication abstraction library
ii  libslp1                     1.0.11-7     OpenSLP libraries
ii  libtasn1-2                  0.2.7-2      Manage ASN.1 structures (runtime)
ii  libwrap0                    7.6.dbs-4    Wietse Venema's TCP wrappers libra
ii  perl [libmime-base64-perl]  5.8.4-2      Larry Wall's Practical Extraction 
ii  psmisc                      21.5-1       Utilities that use the proc filesy
ii  zlib1g                      1:1.2.1.1-3  compression library - runtime

-- debconf information:
  slapd/fix_directory: true
* shared/organization: nodomain
  slapd/upgrade_slapcat_failure: 
  slapd/backend: BDB
* slapd/allow_ldap_v2: false
  slapd/no_configuration: false
  slapd/move_old_database: true
  slapd/suffix_change: false
  slapd/slave_databases_require_updateref: 
  slapd/autoconf_modules: true
* slapd/domain: nodomain
  slapd/password_mismatch: 
  slapd/invalid_config: true
  slapd/upgrade_slapadd_failure: 
  slapd/purge_database: false
  slapd/admin: 

Message #10 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Roland Bauerschmidt <roland@hbg-bremen.de>

To: Hadmut Danisch <debbug2@danisch.de>, 255276@bugs.debian.org

Subject: Re: [debian-openldap] Bug#255276: slapd/slapcat hang in endless loops

Date: Sun, 20 Jun 2004 12:45:02 +0200

Hadmut Danisch wrote:
> since I've upgraded my machine to 2.6.7 slapd
> (and even slapcat) hang. When tracing with strace, 
> they are caught in an endless loop of 
> 
> sched_yield()                           = 0

Does running db4.2_recover in your database directory get your slapd
working again?

Roland

Message #15 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Hadmut Danisch <hadmut@danisch.de>

To: Roland Bauerschmidt <roland@hbg-bremen.de>

Cc: 255276@bugs.debian.org

Subject: Re: [debian-openldap] Bug#255276: slapd/slapcat hang in endless loops

Date: Sun, 20 Jun 2004 16:48:35 +0200

Roland Bauerschmidt wrote:

>
>Does running db4.2_recover in your database directory get your slapd
>working again?
>
>  
>

It seems so. At least slapcat was working again after db4.2_recover.
slapd startet again and seems to be working properly. But it'll take
some time of use to be sure. Nevertheless, good hint. Thanks! :-)

regards
Hadmut

Message #20 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Stephen Frost <sfrost@snowman.net>

To: Hadmut Danisch <debbug2@danisch.de>, 255276@bugs.debian.org

Subject: Re: [debian-openldap] Bug#255276: slapd/slapcat hang in endless loops

Date: Mon, 21 Jun 2004 08:09:32 -0400

[Message part 1 (text/plain, inline)]

* Hadmut Danisch (debbug2@danisch.de) wrote:
> since I've upgraded my machine to 2.6.7 slapd
> (and even slapcat) hang. When tracing with strace, 
> they are caught in an endless loop of 

Others have complained of similar problems.  If running db*_recover
doesn't fix the problem then it may be the case that the new TLS-enabled
glibc is the problem.  Try setting LD_ASSUME_KERNEL=2.4.1 prior to
starting slapd.  That should cause it to link against the old
non-TLS-enable version of glibc.  (NOTE: TLS in this case is
'thread-local storage', nothing to do with 'transport-layer security').

	Stephen

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Marcus Better <marcus.better@abc.se>

To: Debian Bug Tracking System <255276@bugs.debian.org>

Subject: slapd: Similar problem

Date: Fri, 24 Sep 2004 10:22:13 +0200

Package: slapd
Version: 2.1.30-3
Followup-For: Bug #255276

I am using LDAP for authentication with libnss_ldap. I also use
webmin-ldap-useradmin 1.160-1 for managing the LDAP database.

I am trying to add Samba login information to a user account using
webmin, but when I set "Samba login?" to "Yes" in the webmin Edit User
screen and press Save, I get
  "Failed to save user : Failed to modify user in LDAP database : I/O
  Error"
and subsequent attempts to access the LDAP database through webmin fail with
  "Failed to connect to LDAP server 127.0.0.1 port 389."
    

Moreover the LDAP server stops accepting connections:

~$ ldapsearch
ldap_sasl_interactive_bind_s: Can't contact LDAP server (81)
~$ ldapsearch -W -x
Enter LDAP Password:
ldap_bind: Can't contact LDAP server (81)

As a result, it is no longer possible to log in to the system.

Listing the database with slapcat works sometimes, but I have also
experienced that slapcat just hangs, giving no output at all.

Restarting slapd does not help, but if I run db4.2_recover and then
restart slapd, it works normally again.

The LDAP database is very small, containing only 3-4 user entries.

I tried putting the line
  export LD_ASSUME_KERNEL=2.4.1
in /etc/default/slapd and restarting slapd, but it did not help.
    

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8custom
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8

Versions of packages slapd depends on:
ii  coreutils [fileutils]       5.2.1-2      The GNU core utilities
ii  debconf                     1.4.30.5     Debian configuration management sy
ii  libc6                       2.3.2.ds1-16 GNU C Library: Shared libraries an
pi  libdb4.2                    4.2.52-17    Berkeley v4.2 Database Libraries [
ii  libgcrypt11                 1.2.0-4      LGPL Crypto library - runtime libr
ii  libgnutls11                 1.0.16-7     GNU TLS library - runtime library
ii  libgpg-error0               1.0-1        library for common error values an
ii  libiodbc2                   3.51.2-5     iODBC Driver Manager
ii  libldap2                    2.1.30-3     OpenLDAP libraries
ii  libltdl3                    1.5.6-2      A system independent dlopen wrappe
ii  libsasl2                    2.1.19-1.1   Authentication abstraction library
ii  libslp1                     1.0.11-7     OpenSLP libraries
ii  libwrap0                    7.6.dbs-6    Wietse Venema's TCP wrappers libra
ii  perl [libmime-base64-perl]  5.8.4-2.2    Larry Wall's Practical Extraction 
ii  psmisc                      21.5-1       Utilities that use the proc filesy
ii  zlib1g                      1:1.2.1.1-7  compression library - runtime

-- debconf information:
  slapd/fix_directory: true
* shared/organization: Better Home
  slapd/upgrade_slapcat_failure:
  slapd/backend: BDB
* slapd/allow_ldap_v2: false
  slapd/no_configuration: false
  slapd/move_old_database: true
  slapd/suffix_change: false
  slapd/slave_databases_require_updateref:
  slapd/autoconf_modules: true
* slapd/domain: home.better.se
  slapd/password_mismatch:
  slapd/invalid_config: true
  slapd/upgrade_slapadd_failure:
  slapd/purge_database: false
  slapd/admin:

Message #30 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Olivier Berger <olivier.berger@int-evry.fr>

To: Debian Bug Tracking System <255276@bugs.debian.org>

Subject: slapd: Same here : slapcat hangs, and db4.2_verify too

Date: Wed, 05 Jan 2005 10:49:17 +0100

Package: slapd
Version: 2.1.30-3
Followup-For: Bug #255276


Hi. I wanted to report the same thing here.

slapcat is also stuck in an endless loop on sched_yield()

And db4.2_verify gets stuck too.

straceing db4.2_verify gives endless messages like :
select(0, NULL, NULL, NULL, {0, 25000}) = 0 (Timeout)

db4.2_recover was successful though...

Probably a bug in db4.2_verify too ?

After the recover, slapcat works again as expected...

There is a problem somewhere still...

Hope this helps.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages slapd depends on:
ii  coreutils [fileutils]       5.2.1-2      The GNU core utilities
ii  debconf                     1.4.30.11    Debian configuration management sy
ii  fileutils                   5.2.1-2      The GNU file management utilities 
ii  libc6                       2.3.2.ds1-18 GNU C Library: Shared libraries an
ii  libdb4.2                    4.2.52-17    Berkeley v4.2 Database Libraries [
ii  libgcrypt11                 1.2.0-4      LGPL Crypto library - runtime libr
ii  libgnutls11                 1.0.16-9     GNU TLS library - runtime library
ii  libgpg-error0               1.0-1        library for common error values an
ii  libiodbc2                   3.52.1-2     iODBC Driver Manager
ii  libldap2                    2.1.30-3     OpenLDAP libraries
ii  libltdl3                    1.5.6-3      A system independent dlopen wrappe
ii  libsasl2                    2.1.19-1.5   Authentication abstraction library
ii  libslp1                     1.0.11-7     OpenSLP libraries
ii  libwrap0                    7.6.dbs-6    Wietse Venema's TCP wrappers libra
ii  perl [libmime-base64-perl]  5.8.4-3      Larry Wall's Practical Extraction 
ii  psmisc                      21.5-1       Utilities that use the proc filesy
ii  zlib1g                      1:1.2.2-3    compression library - runtime

-- debconf information:
* slapd/password2: (password omitted)
  slapd/internal/adminpw: (password omitted)
* slapd/password1: (password omitted)
  slapd/password_mismatch:
  slapd/fix_directory: true
  slapd/invalid_config: true
* shared/organization: nodomain
  slapd/upgrade_slapcat_failure:
  slapd/upgrade_slapadd_failure:
  slapd/backend: BDB
* slapd/allow_ldap_v2: false
  slapd/no_configuration: false
  slapd/move_old_database: true
  slapd/suffix_change: false
  slapd/slave_databases_require_updateref:
  slapd/autoconf_modules: true
  slapd/purge_database: false
  slapd/admin:
* slapd/domain: nodomain

Message #35 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Olivier Berger <olivier.berger@int-evry.fr>, 255276@bugs.debian.org

Subject: Re: Bug#255276: slapd: Same here : slapcat hangs, and db4.2_verify too

Date: Wed, 9 Mar 2005 13:58:59 +0100

[Message part 1 (text/plain, inline)]

Hi Olivier, 

On Wed, Jan 05, 2005 at 10:49:17AM +0100, Olivier Berger wrote:
 
> slapcat is also stuck in an endless loop on sched_yield()
> And db4.2_verify gets stuck too.
> 
> straceing db4.2_verify gives endless messages like :
> select(0, NULL, NULL, NULL, {0, 25000}) = 0 (Timeout)
> 
> db4.2_recover was successful though...


Always the same question: Still applicable? I never was able to
reproduce this hefty problems...

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Matthew Hawkins <matthew@intology.com.au>

To: 255276@bugs.debian.org

Subject: sched_yield() loop

Date: Wed, 23 Mar 2005 11:39:37 +1100

[Message part 1 (text/plain, inline)]

Hi Torsten,

My ldap box suffered two power outages within 24 hours this week (one
caused by the power company, the other by a well-intentioned but unclued
cow-orker).  On inspection slapd was stuck in a sched_yield() loop.
Doing the db4.2_recover fixed it (I actually came across that hint
elsewhere, I'll try to remember to go to b.d.o first next time ;)

If there is no note, perhaps add one to the README.Debian that if slapd
appears to be consuming all cpu power and this is unexpected, and strace
shows its stuck in sched_yield(), then the bdb database is probably
corrupt and requires recovery using db4.2_recover.

Then you can close this bug and any others like it ;)

Cheers,

-- 
Matt

[Message part 2 (application/pgp-signature, inline)]

Message #53 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Christian Hammers <ch@debian.org>

To: 255276@bugs.debian.org

Subject: Re: slapd/slapcat hang in endless loops

Date: Mon, 25 Apr 2005 00:13:08 +0200

Hello

A month is too long for a RC bug so I dare to ask if there's progress
with this one :)

The bug was marked unreproducible and the last comment from the
submitter was "you can close this bug and any others like it",
so maybe downgrade it a bit and leave it just for reference?

Regarding the issue, if slapd reacts this strange, maybe add this
db_verify command to /etc/init.d/slapd :) (if it does not take too
long).

bye,

-christian-

Message #58 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: 255276@bugs.debian.org

Cc: 255276-submitter@bugs.debian.org

Subject: Fixed in upstream CVS

Date: Wed, 18 May 2005 12:21:23 +0200

See this message below.  Recent OpenLDAP versions will recover
automatically, as needed.

Rumor has it that Berkeley DB 4.4 will offer similar functionality,
too.

From: Howard Chu <XYZ.hyc@highlandsun.com>
Subject: Re: Force single thread of control during recovery
Newsgroups: comp.databases.berkeley-db
Date: Sun, 15 May 2005 16:42:07 -0700
Message-ID: <Pa6dndTDI83PQxrfRVn-hA@comcast.com>

oleksandr kalinin wrote:
> Hello All,
> In my environment, there is a command-line database maintenance tool
> for
> users to display, add, modify records etc. During recovery, I would have to
> make sure this tool does not attempt to open the environment so that there
> is only single thread of control accessing it. Seems like I have to
> implement own locking mechanism to handle this, or is there some "smarter"
> way, e.g. in the library? Locking is easy in this case, but just to make
> sure I haven't missed something important in documentation... Many thanks
> for your help.

The current releases of the BDB library don't offer any support here. We 
wrote our own locking mechanism for OpenLDAP to mediate access to the 
environment. We record the process IDs of all processes with a valid 
handle to the environment, so we can detect unclean exits and force a 
recovery only when needed. And of course, only one process can trigger a 
recovery. The code is in OpenLDAP's CVS if you're interested, 
servers/slapd/back-bdb/alock.c

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

Message #66 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Eugene Konev <ejka@imfi.kspu.ru>

To: 255276@bugs.debian.org

Subject: Re: slapd/slapcat hang in endless loops

Date: Mon, 23 May 2005 01:40:11 +0800

After experimenting with different kinds of slapd database corrution on
2.2.23 I've found out that this behavior is hapenning then db
environment files (/var/lib/ldap/__db.00[1-5]) are missing or severely
corrupted. 
ltracing slapd shows that it stucks in dbenv_open, so it's problem in
berkeley db, not slapd itself. 
Most times (when logs were not severely corrupted as far as I can say)
it was possible to recover situation by running db4.2_recover. So I'd
also suggest adding call to db4.2_recover somewhere in the init-script.

Message #71 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Eugene Konev <ejka@imfi.kspu.ru>, 255276@bugs.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Mon, 23 May 2005 17:11:44 +0200

[Message part 1 (text/plain, inline)]

On Mon, May 23, 2005 at 01:40:11AM +0800, Eugene Konev wrote:
> After experimenting with different kinds of slapd database corrution on
> 2.2.23 I've found out that this behavior is hapenning then db
> environment files (/var/lib/ldap/__db.00[1-5]) are missing or severely
> corrupted. 
> ltracing slapd shows that it stucks in dbenv_open, so it's problem in
> berkeley db, not slapd itself. 
> Most times (when logs were not severely corrupted as far as I can say)
> it was possible to recover situation by running db4.2_recover. So I'd
> also suggest adding call to db4.2_recover somewhere in the init-script.

Looks like we should do that after bazillions of people requested it.
Any suggestions how to implement this correctly?

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Eugene Konev <ejka@imfi.kspu.ru>

To: Torsten Landschoff <torsten@debian.org>

Cc: 255276@bugs.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Wed, 25 May 2005 23:26:03 +0800

[Message part 1 (text/plain, inline)]

Hello Torsten.

 On Mon, 23 May 2005 17:11:44 +0200
 you wrote:

 TL> Looks like we should do that after bazillions of people requested it.
 TL> Any suggestions how to implement this correctly?

The attached patch adds calling db4.2_recover to slapd.init on every
slapd startup.

[slapd.init.diff (text/plain, attachment)]

Message #81 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Eugene Konev <ejka@imfi.kspu.ru>, 255276@bugs.debian.org

Cc: pkg-openldap-devel@lists.alioth.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Wed, 25 May 2005 17:02:42 -0700

[Message part 1 (text/plain, inline)]

On Wed, May 25, 2005 at 11:26:03PM +0800, Eugene Konev wrote:

>  On Mon, 23 May 2005 17:11:44 +0200
>  you wrote:

>  TL> Looks like we should do that after bazillions of people requested it.
>  TL> Any suggestions how to implement this correctly?

> The attached patch adds calling db4.2_recover to slapd.init on every
> slapd startup.

Are there any objections to applying this patch for sarge?

-- 
Steve Langasek
postmodern programmer

> diff -Nru openldap2.2-2.2.23/debian/slapd.init openldap2.2-hack/debian/slapd.init
> --- openldap2.2-2.2.23/debian/slapd.init	2005-05-24 19:42:21.000000000 +0800
> +++ openldap2.2-hack/debian/slapd.init	2005-05-25 23:15:35.000000000 +0800
> @@ -48,6 +48,10 @@
>  		"$SLAPD_CONF"`
>  fi
>  
> +# Find out slapd db directories
> +SLAPD_DBDIRS=`sed -ne 's/^directory[[:space:]]\+"*\([^"]\+\).*/\1/p' \
> +                "$SLAPD_CONF" `
> +	
>  # XXX: Breaks upgrading if there is no pidfile (invoke-rc.d stop will fail)
>  # -- Torsten
>  if [ -z "$SLAPD_PIDFILE" ]; then
> @@ -107,6 +111,24 @@
>  }
>  
>  
> +# Try to recover slapd database
> +try_fix_db() {
> +	if [ "$SLAPD_TRYFIXDB" != yes -o \
> +	      -z "$SLAPD_DBDIRS" ]; then
> +		return 0
> +	fi
> +	echo -n " (possibly) fixing db,"
> +	for DBDIR in $SLAPD_DBDIRS; do
> +	    if [ -d "$DBDIR" -a -f "$DBDIR/objectClass.bdb" ]; then
> +		db4.2_recover -eh $DBDIR 2>&1
> +		if [ $? -ne 0 ]; then
> +		    reason="Automatic recovery of slapd database failed. You will need to perform recovery by hand, possibly from backup."
> +		    exit 1
> +		fi
> +	    fi
> +	done
> +}
> +
>  # Start the slapd daemon and capture the error message if any to 
>  # $reason.
>  start_slapd() {
> @@ -157,6 +179,7 @@
>  start() {
>  	echo -n "Starting OpenLDAP:"
>  	trap 'report_failure' 0
> +	try_fix_db
>  	start_slapd
>  	start_slurpd
>  	trap "-" 0

[signature.asc (application/pgp-signature, inline)]

Message #86 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Steve Langasek <vorlon@debian.org>, 255276@bugs.debian.org

Cc: Eugene Konev <ejka@imfi.kspu.ru>, pkg-openldap-devel@lists.alioth.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Thu, 26 May 2005 09:35:09 +0200

[Message part 1 (text/plain, inline)]

Hi Steve, 

On Wed, May 25, 2005 at 05:02:42PM -0700, Steve Langasek wrote:
> > The attached patch adds calling db4.2_recover to slapd.init on every
> > slapd startup.
> 
> Are there any objections to applying this patch for sarge?

I'll apply it with some adaptions. Most prominently it should check for
the database type before running db_recover.

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #91 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Eugene Konev <ejka@imfi.kspu.ru>

Cc: 255276@bugs.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Thu, 26 May 2005 16:53:17 +0200

[Message part 1 (text/plain, inline)]

Hi Eugene, 

On Wed, May 25, 2005 at 11:26:03PM +0800, Eugene Konev wrote:
 
> The attached patch adds calling db4.2_recover to slapd.init on every
> slapd startup.

Thanks again for the patch. I am currently working to apply your
changes. A few remarks while I am working on it:

> diff -Nru openldap2.2-2.2.23/debian/slapd.init openldap2.2-hack/debian/slapd.init
> --- openldap2.2-2.2.23/debian/slapd.init	2005-05-24 19:42:21.000000000 +0800
> +++ openldap2.2-hack/debian/slapd.init	2005-05-25 23:15:35.000000000 +0800
> @@ -48,6 +48,10 @@
>  		"$SLAPD_CONF"`
>  fi
>  
> +# Find out slapd db directories
> +SLAPD_DBDIRS=`sed -ne 's/^directory[[:space:]]\+"*\([^"]\+\).*/\1/p' \
> +                "$SLAPD_CONF" `
> +	

I'd rather gather this list at the time when it is needed. Apart from
that I don't really grok that sed expression :)

> +# Try to recover slapd database
> +try_fix_db() {
...
> +	if [ "$SLAPD_TRYFIXDB" != yes -o \
That switch makes no sense inside fix_db I'd say. I used to do it like
this but stumbled across it later because I was using that function
later and it did not do anything because it checked some magic variable.
Not going to happen here I'd say, but for consistency I'll move that
check.

> +	echo -n " (possibly) fixing db,"
I don't like that message - as a user I am not going to understand
what's going on there. Changed to "running BDB recovery".

> +	for DBDIR in $SLAPD_DBDIRS; do
> +	    if [ -d "$DBDIR" -a -f "$DBDIR/objectClass.bdb" ]; then
Did not see that check at the first glance. Moving it to the point where
the list of BDB directories is collected. 

> +		db4.2_recover -eh $DBDIR 2>&1
What is that -e option about? I do not really understand the meaning.
Guess I'll keep it enabled. Perhaps it would be a good idea to install
a DB_CONFIG during upgrade and run db_recover without -e to get the new
settings!?

@Steve: What would you think about such a change?

> +		if [ $? -ne 0 ]; then
That will not work because of the "set -e" up in that file. The script
will bail out if db_recover fails and will never get to that check. It's
better to run 

	db4.2_recover ... || do stuff in case of failure

or run db_recover inside an if but that will hide the real functionality
of db_recover as an side effect of the if. 


I attached my current patch (currently building slapd to test it).
Suggestions welcome :)

Greetings

	Torsten

[255276.diff (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #100 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Eugene Konev <ejka@imfi.kspu.ru>

To: Torsten Landschoff <torsten@debian.org>

Cc: 255276@bugs.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Fri, 27 May 2005 09:10:50 +0800

Hello Torsten.

 On Thu, 26 May 2005 16:53:17 +0200
 you wrote:

 >> +# Find out slapd db directories
 >> +SLAPD_DBDIRS=`sed -ne 's/^directory[[:space:]]\+"*\([^"]\+\).*/\1/p' \
 >> +                "$SLAPD_CONF" `
 >> +        

 TL> I'd rather gather this list at the time when it is needed. Apart from
 TL> that I don't really grok that sed expression :)

It has only possible failure if path contains double quotes in it, which
is very unlikely situation. And this:

 TL> +# Find bdb environment dirs
 TL> +find_bdb_envs() {
 TL> +        local d
 TL> +        for d in `awk '/directory/ {print $2}' < "$SLAPD_CONF"`; do
 TL> +                if [ -d "$d" -a -f "$d/objectClass.bdb" ]; then
 TL> +                        echo $d
 TL> +                fi
 TL> +        done
 TL> +}

will happily skip entries like:
directory    "/var/lib/ldap"
(note the quotes), which are by default in sarge install.

Message #105 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: 255276@bugs.debian.org

Subject: Patch to run database recovery on startup

Date: Fri, 27 May 2005 08:27:47 +0200

The patch is risky.  After it's been applied, invoking
"/etc/init.d/slapd start" while slapd is running can (and most
probably will) result in data loss.

"db4.2_recover -e" will pick up new DB_CONFIG settings, so there's no
need to special-case it for updates.

Message #110 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Florian Weimer <fw@deneb.enyo.de>, 255276@bugs.debian.org

Subject: Re: Bug#255276: Patch to run database recovery on startup

Date: Fri, 27 May 2005 18:25:19 +0200

[Message part 1 (text/plain, inline)]

Hi Florian, 

On Fri, May 27, 2005 at 08:27:47AM +0200, Florian Weimer wrote:
> The patch is risky.  After it's been applied, invoking
> "/etc/init.d/slapd start" while slapd is running can (and most
> probably will) result in data loss.

Yep, that is creating headaches for me too :(

> "db4.2_recover -e" will pick up new DB_CONFIG settings, so there's no
> need to special-case it for updates.

Are you sure? I though "-e" was to retain the old setting?

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #115 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Eugene Konev <ejka@imfi.kspu.ru>

Cc: 255276@bugs.debian.org

Subject: Re: Bug#255276: slapd/slapcat hang in endless loops

Date: Fri, 27 May 2005 18:27:39 +0200

[Message part 1 (text/plain, inline)]

On Fri, May 27, 2005 at 09:10:50AM +0800, Eugene Konev wrote:
 
>  >> +# Find out slapd db directories
>  >> +SLAPD_DBDIRS=`sed -ne 's/^directory[[:space:]]\+"*\([^"]\+\).*/\1/p' \
>  >> +                "$SLAPD_CONF" `
>  >> +        
> 
>  TL> I'd rather gather this list at the time when it is needed. Apart from
>  TL> that I don't really grok that sed expression :)
> 
> It has only possible failure if path contains double quotes in it, which
> is very unlikely situation. And this:

Yes, I was able to parse it finally :)

>  TL> +# Find bdb environment dirs
>  TL> +find_bdb_envs() {
>  TL> +        local d
>  TL> +        for d in `awk '/directory/ {print $2}' < "$SLAPD_CONF"`; do
>  TL> +                if [ -d "$d" -a -f "$d/objectClass.bdb" ]; then
>  TL> +                        echo $d
>  TL> +                fi
>  TL> +        done
>  TL> +}
> 
> will happily skip entries like:
> directory    "/var/lib/ldap"
> (note the quotes), which are by default in sarge install.

Yep. I was using eval to strip them and removed that before sending the
email as it can have really serious results depending on your
slapd.conf.

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #120 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Torsten Landschoff <torsten@debian.org>

Cc: 255276@bugs.debian.org

Subject: Re: Bug#255276: Patch to run database recovery on startup

Date: Fri, 27 May 2005 19:00:20 +0200

* Torsten Landschoff:

>> "db4.2_recover -e" will pick up new DB_CONFIG settings, so there's no
>> need to special-case it for updates.
>
> Are you sure?

Yes, I regularly use "-e" to recreate the environment after tweaking
DB_CONFIG.

> I though "-e" was to retain the old setting?

"-e" does not retain any settings, it retains the environment.  The
settings are taken from DB_CONFIG and the compiled-in default values,
not from the previous environment configuration.

Message #125 received at 255276@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Torsten Landschoff <torsten@debian.org>

Cc: 255276@bugs.debian.org

Subject: Re: Bug#255276: Patch to run database recovery on startup

Date: Fri, 27 May 2005 22:40:23 +0200

* Florian Weimer:

>> I though "-e" was to retain the old setting?
>
> "-e" does not retain any settings, it retains the environment.

It retains it by removing and recreating it (sorry for being unclear).

Message #130 received at 255276-close@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: 255276-close@bugs.debian.org

Subject: Bug#255276: fixed in openldap2.2 2.2.23-6

Date: Sun, 29 May 2005 13:34:57 -0400

Source: openldap2.2
Source-Version: 2.2.23-6

We believe that the bug you reported is fixed in the latest version of
openldap2.2, which is due to be installed in the Debian FTP archive:

ldap-utils_2.2.23-6_i386.deb
  to pool/main/o/openldap2.2/ldap-utils_2.2.23-6_i386.deb
libldap-2.2-7_2.2.23-6_i386.deb
  to pool/main/o/openldap2.2/libldap-2.2-7_2.2.23-6_i386.deb
openldap2.2_2.2.23-6.diff.gz
  to pool/main/o/openldap2.2/openldap2.2_2.2.23-6.diff.gz
openldap2.2_2.2.23-6.dsc
  to pool/main/o/openldap2.2/openldap2.2_2.2.23-6.dsc
slapd_2.2.23-6_i386.deb
  to pool/main/o/openldap2.2/slapd_2.2.23-6_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 255276@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Torsten Landschoff <torsten@debian.org> (supplier of updated openldap2.2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 29 May 2005 18:23:20 +0200
Source: openldap2.2
Binary: slapd ldap-utils libldap-2.2-7
Architecture: source i386
Version: 2.2.23-6
Distribution: unstable
Urgency: low
Maintainer: Torsten Landschoff <torsten@debian.org>
Changed-By: Torsten Landschoff <torsten@debian.org>
Description: 
 ldap-utils - OpenLDAP utilities
 libldap-2.2-7 - OpenLDAP libraries
 slapd      - OpenLDAP server (slapd)
Closes: 255276 303505 306229 308234 310422
Changes: 
 openldap2.2 (2.2.23-6) unstable; urgency=low
 .
   Torsten Landschoff <torsten@debian.org>:
   * debian/po/ja.po: Merge updates from Kenshi Muto (closes: #303505).
   * debian/po/fr.po: Merge updates from Christian Perrier (closes: #306229).
   * debian/slapd.scripts-common: If the user enters the empty value for
     the database dumping directory use the default value. Seems like the
     readline interface does not care about the default value
     (closes: #308234).
   * debian/slapd.postinst: Make sure the debhelper commands are executed
     in all cases (closes: #310422).
   * Merged suggested changes by Eugene Konev to automatically run
     db_recover before starting slapd (closes: #255276).
     + debian/slapd.init: Run db_recover if enabled and available and no
       slapd process running.
     + debian/slapd.default: Add configuration option to disable it.
   * Applied and improved patch by Matthijs Mohlmann to support migration
     from ldbm to bdb backend.
     + debian/slapd.config: Ask if migration is wanted.
     + debian/slapd.postinst: Update configuration from ldbm to bdb if yes.
     + debian/slapd.scripts-common: Implemented some parts in their own
       functions.
   * Add a README.DB_CONFIG.gz and reference it where referring to BDB
     configuration.
   * Update default DB_CONFIG with some senseful values.
 .
   Steve Langasek <vorlon@debian.org>:
   * libraries/libldap_r/Makefile.in: make sure the ximian-connector ntlm
     patch is applied to libldap_r, not just to libldap
   * debian/move_files: make libldap a symlink to libldap_r, as carrying
     two versions of this library around is more trouble than it's worth,
     and can cause glorious segfaults down the line
Files: 
 1b46caee7a3377aff6ab29c3034dde86 1035 net optional openldap2.2_2.2.23-6.dsc
 20983ed8e341b87a04116cd7db075e20 489688 net optional openldap2.2_2.2.23-6.diff.gz
 80f24b17e4700ef5b8763c13f8051d3e 809150 net optional slapd_2.2.23-6_i386.deb
 8e72f04c89b139f48da941138113fa5a 118614 net optional ldap-utils_2.2.23-6_i386.deb
 73b838fd8862e1b6c2fd7e029dc84d47 151250 libs important libldap-2.2-7_2.2.23-6_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCmfsCdQgHtVUb5EcRAj1rAJwPK6SUSnp1F8D0jy5j4rUUc4CksACfdNCI
gb84g+HfrrjhwJuSVlH0CQg=
=r31z
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.