LDAP: « bdb_db_open: unclean shutdown detected »

30 comments // août 18th, 2008 // Debian, Réseaux

Lundi matin, une journée qui commence bien. Le service « slapd » étant arrêté, je me jette dans les logs et voilà ce que j’y trouve:
bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.

Après quelques recherches sur « db_recover » et après avoir essayé de lire les pages man introuvables… je me lance à la sauvage:
/etc/init.d/ldap stop
db_recover -v -h /var/lib/ldap
/etc/init.d/ldap start

Le service repart, puis s’écroule quelques minutes plus tard en m’insultant de la même façon. Seule option restante: Récupérer les .bdb stocké sur la bande de sauvegarde de la veille:
/etc/init.d/ldap stop
A la recherche de mes fichiers:
tar tvf /dev/st0 | grep *.bdb
Ouf, tout est là: On restaure.
tar xvf /dev/st0 var/lib/ldap
Si, comme moi, vos fichiers font plus de 2Go, allez donc boire une cafetière de café.. ou prendre un Xanax..
slapd -d 256
Je vous passe le tas de logs qu’il m’a vomi à ce moment précis -c’est plutôt bon signe- il est enfin lancé… et à l’air de s’y plaire. Attention à ne pas le stopper à l’aide d’un CTRL+C, ce qui pourrais causer une nouvelle corruption ! Pour cela on va lui demander plus poliment:
kill -INT ‛cat /var/run/ldap/slapd.pid‛
Puis on relance, proprement:
/etc/init.d/ldap start

Note: n’oubliez pas de vérifier que les fichiers contenus dans le répertoire /var/lib/ldap appartiennent bien à ldap:ldap après la restauration, c’est du vécu..

Possibly Related Posts:

anass says:

bonjour adrien
voila je suis entrain de mettre en place un serveur openldap sous fedora 10 et lorsque je lance service ldap start
il m envoie les erreurs suivantes:

bdb_db_open: database « dc=glaizer,dc=net »: unclean shutdown detected; attempting recovery.
bdb_db_open: database « dc=glaizer,dc=net »: recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb(dc=glaizer,dc=net): /var/lib/ldap/dn2id.bdb: file size not a multiple of the pagesize
bdb_db_open: database « dc=glaizer,dc=net »: db_open(/var/lib/ldap/dn2id.bdb) failed: Invalid argument (22).
bdb(dc=glaizer,dc=net): Database handles still open at environment close
bdb(dc=glaizer,dc=net): Open database handle: id2entry.bdb
bdb_db_close: database « dc=glaizer,dc=net »: close failed: Invalid argument (22)
backend_startup_one: bi_db_open failed! (22)
slap_startup failed (test would succeed using the -u switch)
stale lock files may be present in /var/lib/ldap

apparemment vous vous y connaissez bcp plus que moi qui suis debutant si vous avez des documents pour m aider ou des commandes pour resoudre ces erreurs priere de m aider
et merci

Répondre

août 18, 2008, 16:07

Adri says:

avez vous essayé le:
# db_recover -v -h /var/lib/ldap

août 18, 2008, 16:29

oui
fedora ne reconnait pas db_recover :s
# db_recover -v -h /var/lib/ldap
bash: db_recover: command not found

août 18, 2008, 16:32

ok, est ce que le paquet « db4.2-util » (ou une version différente) est installé ?

août 18, 2008, 16:43

alors la aucune idée il sert a koi
voici ce que j ai obtenu en essayant de l installé

yum install db4.2-util
Modules complémentaires chargés : refresh-packagekit
fedora | 2.8 kB 00:00
updates | 2.3 kB 00:00
adobe-linux-i386 | 951 B 00:00
Configuration du processus d’installation
Traitement des options d’installation des paquetages
No package db4.2-util available.
Rien à faire

il sert a koi et sinon quelles sont les autres versions et merci

août 18, 2008, 16:56

je ne connais pas trop fédora mais après quelques recherches l’utilitaire pourrais se nommer:

slapd_db_recover

août 18, 2008, 17:13

il dit que y a pas de slapd_db_recover available

août 18, 2008, 9:45

Malheureusement pour toi je ne connais pas du tout l’environnement LDAP sur Fedora, a mon avis pour résoudre ton problème il te faut trouver le paquet contenant l’outil db_recover ou bien le compiler depuis les sources..

pas de /usr/sbin/slapd_db_recover non plus ?

août 18, 2008, 14:17

c bon j ai reformaté ma machine et la ça marche comme par enchantement :D
je te tiendrai au courant de mon evolution :p
merci bcp

août 18, 2008, 15:12

bonjour me revoila avec une nouvelle erreur
:)

[root@localhost openldap]# ldapadd -W -D « cn=Manager,o=test,c=net » -xh localhost -f /etc/openldap/base.ldiff
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN

août 18, 2008, 10:32

rebonjour j ai résolu l erreur précedente et la j ai celle ci

[root@localhost openldap]# ldapadd -W -D ‘cn=manager,dc=society,dc=net’ -xh localhost -f /home/anass/Bureau/society.txt
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

et je m excuse pour le derangement

août 18, 2008, 13:30

Comme l’erreur le dit: problème de mot de passe ;)

août 18, 2008, 14:46

je l ai changé avec la commande slappasswd : {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU
et remplacé dans le slapd.conf et dans base et tjrs le mm probleme

voici mon fichier base.ldif:
# Organization for Samba Base

dn: dc=society,dc=net

objectclass: dcObject

objectclass: organization

dc: glaizer

o: Samba 3

description: Samba 3

# Manager LDAP

dn: cn=manager,dc=society,dc=net

objectclass: organizationalRole

cn: manager

description: LDAP Manager

# Conteneur d’utilisateurs

dn: ou=Users,dc=society,dc=net

objectclass: top

objectclass: organizationalUnit

ou: Users

# Conteneur de machines

dn: ou=Computers,dc=society,dc=net

ou: Computers

# Administrateur

dn: cn=admin,ou=Users,dc=society,dc=net

cn: admin

objectclass: simpleSecurityObject

userPassword: {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU

août 18, 2008, 15:11

voila adri c ma configuration et je vois pas prkoi ça ne marche pas :s

[root@localhost anass]# ldapadd -D « cn=manager,o=company,c=net » -W -f /etc/openldap/base.ldif
Enter LDAP Password:
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid DN syntax (34)

here is my ldap.conf:

# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
URI ldap://127.0.20.1/
BASE dc=company,dc=net
TLS_CACERTDIR /etc/openldap/cacerts
[/SIZE][/SIZE]

my base.ldif is :

#Organization for Samba Base

dn: dc=company,dc=net

dc: company

dn: cn=manager,dc=company,dc=net

dn: ou=Users,dc=company,dc=net

dn: ou=Computers,dc=company,dc=net

dn: cn=admin,ou=Users,dc=company,dc=net

and my slapd.conf is:

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database bdb
suffix « dc=company,dc=net »
checkpoint 1024 15
rootdn « cn=manager,dc=company,dc=net »
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
rootpw {SSHA}WW2PMcKsh0ZVrFFSuwAtAXIUISAq1VIU

# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap

# Indices to maintain for this database
#index objectClass eq,pres
#index ou,cn,mail,

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM

# enable monitoring
database monitor

# allow onlu rootdn to read the monitor
access to *
by dn.exact= »cn=manager,dc=company,dc=net » read
by * none

août 18, 2008, 16:04

bobo says:

Bonjour,

J’ai un gros problème sur Ldap, en effet lorsque je rentre une entrée sur le ldap maitre, celle ci va être insérée dans un fichier nommé sluprd.replog, puis grâce au daemon slurpd va être lu pour être injecté dans mon serveur de réplication ldap

Tout fonctionne, mais si je fais genre 15 entrées le fichier slurpd.replog va être saturé en écriture et a partir de la c’est tout le serveur qui lague.Le fichier atteint les 7 GO o_O .

Si je coupe le ldap puis le relance voila le message d’erreur :

Vérification des fichiers de configuration pour slapd : bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered. config file testing succeeded

J’ai fais un slap_db_recover mais l’erreur va réapparaitre au bout d’une quinzaine d’entrées.

Avez vous déjà eu le problème???

Faut t’il paramétrer le fichier DB_CONFIG ???

Merci :p

août 18, 2008, 16:10

Aye, je ne vais pas du tout pouvoir t’aider puisque j’ai toujours utilisé syncrepl et je ne connais pas du tout slurpd.. que disent les logs ?

août 18, 2008, 16:22

merci de ta réponse :)

Pour les logs rien de spécial, la réplication se fait c’est tout :(

Je connais pas syncrepl ça marche comment???

août 18, 2008, 16:34

Je vais tester ça demain ^^

Ca remplace slurpd apparemment un espoir peut etre :)

août 18, 2008, 16:36

ça marche bien !
Plus sérieusement, tu fait quelques modifs dans les /etc/ldap/slapd.conf, tu charge le modules qui va bien… et ça roule !
Tu as pas mal de tutos qui t’expliquerons bien mieux que moi en quelques lignes.

http://www.google.fr/search?q=syncrepl

;)

août 18, 2008, 16:52

hello toujours la???

je veux charger ce module
« moduleload syncprov.la »

Mais il n’existe pas sur ma distrib :(

Tu aurais le slapd.conf qui va bien :)

Ou juste ce que tu as rajouter pour la réplciation sur le maitre et serveur.

Si c’est possible :)

Merci

août 18, 2008, 9:16

essaye simplement: « moduleload syncprov », ça devrait rouler tout seul !

août 18, 2008, 14:40

ok ça marche nikel merci :)

août 18, 2008, 15:06

Par contre il faut mettre de moduleload sur centos, tout est intégré avec slapd

août 18, 2008, 8:07

merci pour la précision ;)

août 18, 2008, 10:58

Au fait, comprend tu précisément le fonctionnement de syncrepl?

j’ai trouvé ce site, pour le mode 7.2.1.2.2 Replication refreshAndPersist (provider Push)

http://www.zytrax.com/books/ldap/ch7/

Mais l’histoire du cookie je ne comprends pas trop :(

Le serveur envoie un cookie avec un timestamp indiquant le dernier changement effectué, un truc du genre

overlay syncprov

# Le contextCSN (cookie) est écrit toutes les 100 opérations d’écriture ou toutes
# les 10 minutes.
syncprov-checkpoint 100 10
# Les logs de session gardent en mémoire presque toutes les opérations
# d’écriture sur la base, cela permet d’interroger les logs plutôt que de
# faire des requêtes sur la base. Jusqu’à 100 opérations sont
# enregistrées dans cette exemple.
syncprov-sessionlog 100

# Le contextCSN (cookie) est écrit toutes les 100 opérations d’écriture ou toutes les 10 minutes.

Donc comment se fait la synchro si c’est tous les 10 minutes, ca se fait en temps réel, cette option ne sert a rien?

Enfin si tu peux m’éclairer sur le fonctionnement :)

août 18, 2008, 16:09

En fait les cookies de réplication servent a vérifier si les serveurs sont bien synchronisés en comparant directement les timestamps (contenu dans ces cookies).
–
Dans le mode refreshOnly, la synchronisation programmé selon un intervalle de temps – spécifié par le paramètre « interval ». Par défaut: 1 jour alors que dans le mode refreshAndPersist, la synchronisation est persistante… presque temps-réel.

ok merci de ta réponse

donc syncprov-checkpoint 100 10 ==> sur le maitre est complètement inutile?

août 18, 2008, 18:09

au contraire, il est indispensable. Tiens, je te conseille de lire cet article qui est vraiment très bien foutu: http://www.zytrax.com/books/ldap/ch7/

août 18, 2008, 12:07

Michel says:

J’ai le même problème (bdb_db_open: unclean shutdown detected) mais sur une machine virtuelle KVM (CentOS 5) exécutée dans une Fedora 12.
Avez-vous une idée de la manière d’effectuer un db_recover dans ces conditions ?

Le message exact est:
Vérification des fichiers de configuration pour slapd :
bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Warning – No DB_CONFIG file found in directory /var/lib/ldap: (2)
Expect poor perfomance for suffix dc=dclic, dc=fr.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
config file testing succeeded.

Et le système ne répond plus.

août 18, 2008, 10:42

Debian or not to be ? 2.0

LDAP: « bdb_db_open: unclean shutdown detected »

// Qui suis-je ?

// Articles aléatoires.

// Bookmarks.

// Categories.

// Tags.

// Donations.