Hello Merci Xavier pour les infos. J'avais regarde dans ce fichier /var/lib/ldap/DB_CONFIG au moment de la config initiale et j'avais laissé les settings par defaut:
set_cachesize 0 15000000 1 set_lg_bsize 2097152 Par compte, ma directive cachesize dans slapd.conf est à 2000 (cad 10 fois la valeur par defaut), je vais aussi augmenter celle de DB_CONFIG et voir ce qui arrive apres un db_recover.. Je vais encore un peu creuser la doc, mais depuis que je prends le backup 'online' je n'ai plus eu de crash (faudrait pas que je l'écrive trop vite sinon ca va encore m'exploser à la tronche ;-) On Tue, 14 Jun 2005, Xavier Renard wrote: > Salut Vincent, > > J'irai dans ces directions: > 1)la version de berkeley est la 4.2.52. Normalement, avec cette version > il fallait appliquer quelque patch > mais je ne sais pas si suse les a inclut. > 2)Des problèmes comme ceux que tu as (mais on en a jamais eu) peuvent > arriver si berkeley db n'est pas configuré > et que par exemple la cache n'est pas assez grande(d'où ça "hang") > > Il faut lire "attentivement" > le man slapd-bdb > et ces liens-ci: > http://www.openldap.org/faq/data/cache/1075.html > http://www.openldap.org/faq/data/cache/893.html > http://www.openldap.org/faq/data/cache/1072.html > > Courage :-) > > Xavier > > > Vincent Jamart wrote: > > >Hello > > > >J'ai +-7000 entrées. Je viens de changer le script, puisque c'est du BDB > >je vais faire un slapcat -f /etc/openldap/slapd.conf -b "dc=fft,dc=be" -l > >backup.ldif avec la DB ouverte. > > > > > >On Fri, 10 Jun 2005, Xavier Renard wrote: > > > > > > > >>Hi, > >> > >>C'est bizarre quand meme. Tu as combien d'entrée? > >>Sinon, au niveau debug, essaye peut-etre un niveau plus élevé > >>avec la directive loglevel: > >>http://www.openldap.org/doc/admin22/slapdconfig.html#Configuration%20File%20Directives > >>(cfr section 5.2.1.5 pour les différents niveaux) > >> > >>ou avec l'option -d de slapd > >> > >> > >>Xavier > >> > >>Vincent Jamart wrote: > >> > >> > >> > >>>Hello > >>> > >>>A nouveau, la DB est corrompue ce matin mais cette fois-ci, le FS n'est > >>>pas en cause puisque 95%. Le daemon est stoppé et lordsque je le > >>>redémarre, localmessages n'affiche pas d'erreurs: > >>>Jun 10 09:05:19 hera slapd[1371]: @(#) $OpenLDAP: slapd 2.2.15 (Jan 26 > >>>2005 16:34:33) $ > >>>[EMAIL PROTECTED]:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd > >>> > >>> > >>>Jun 10 09:05:19 hera slapd[1371]: bdb_initialize: Sleepycat Software: > >>>Berkeley DB 4.2.52: (October 1, 2004) Jun 10 09:05:20 hera slapd[1371]: > >>>bdb_db_init: Initializing bdb database > >>>Jun 10 09:05:20 hera slapd[1376]: slapd starting Jun 10 09:05:20 hera > >>>slapd[1376]: conn=0 fd=12 ACCEPT from IP=127.0.0.1:51261 (IP=0.0.0.0:389) > >>>Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 BIND dn="" method=128 > >>>Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 RESULT tag=97 err=0 text= > >>>Jun 10 09:05:20 hera slapd[1376]: connection_input: conn=0 deferring > >>>operation: binding Jun 10 09:05:20 hera slapd[1376]: conn=0 op=1 SRCH > >>>base="" scope=0 deref=0 filter="(objectClass=*)" > >>> > >>> > >>>Par compte, si je fais un ldapsearch -x, il s'arrête tout de suite: > >>>hera:/var/log # ldapsearch -x > >>># extended LDIF > >>># > >>># LDAPv3 > >>># base <> with scope sub > >>># filter: (objectclass=*) > >>># requesting: ALL > >>># > >>> > >>># fft.be > >>>dn: dc=fft,dc=be > >>>o: fft > >>>dc: fft > >>>objectClass: top > >>>objectClass: dcObject > >>>objectClass: organization > >>> > >>># Manager, fft.be > >>>dn: cn=Manager,dc=fft,dc=be > >>>cn: Manager > >>>sn: Manager > >>>objectClass: top > >>>objectClass: person > >>> > >>># People, fft.be > >>>dn: ou=People,dc=fft,dc=be > >>>ou: People > >>>objectClass: top > >>>objectClass: organizationalUnit > >>> > >>> > >>>Je dois faire un ^C pour reprendre la main et db_recover n'y change rien. > >>> > >>>Ca arrive trop souvent, sans logique et je n'ai plus confiance dans ce > >>>package bdb +openldap (en tout cas le RPM de Suse). Activer un PDC windows > >>>me prendrait moins de temps que débugger ce brol... > >>> > >>>On Fri, 3 Jun 2005, Vincent Jamart wrote: > >>> > >>> > >>> > >>> > >>> > >>_______________________________________________________ > >>Linux Mailing List - http://www.unixtech.be > >>Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > >>Archives: http://www.mail-archive.com/linux@lists.unixtech.be > >>IRC: chat.unixtech.be:6667 - #unixtech > >>NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech > >> > >> > >> > > > >_______________________________________________________ > >Linux Mailing List - http://www.unixtech.be > >Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > >Archives: http://www.mail-archive.com/linux@lists.unixtech.be > >IRC: chat.unixtech.be:6667 - #unixtech > >NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech > > > > > > > > > > _______________________________________________________ > Linux Mailing List - http://www.unixtech.be > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > Archives: http://www.mail-archive.com/linux@lists.unixtech.be > IRC: chat.unixtech.be:6667 - #unixtech > NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech > _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
