Ciao,
per cercare di venire a capo del problema, esposto nella mail in calce, ho lanciato due consumer con il debug -d 16384 (relativo ai messaggi del syncrepl) un consumer ha il syncrepl type settato a refreshOnly mentre l'altro è settato a refreshAndPersistent, ho notato che vi sono messaggi relativi alla mancata connessione tipo questo: do_syncrep2: rid 015 LDAP_RES_SEARCH_RESULT connection_read(27): no connection! request done: ld 1d17200 msgid 1 request done: ld 1d17200 msgid 2 dove il numeretto tra le parentesi cambia ma non riesco a trovare informazioni circa il significato di tale numeretto, mi potete dare qualche indicazione? Ultima domanda quale dei due type disponibili per il syncrepl è più affidabile? refreshOnly o refreshAndPersistent. Da quello che ho capito il primo effettua il polling ed il provider gli lascia un cookie per il successivo polling quindi la connessione viene aperta e chiusa ad ogni polling, nel secondo la connessione tra provider e consumer è sempre stabilita ed il provider avverte il consumer tramite scambio di cookie nel momento che sono state effettuate nuove operazioni (add, mod, del) così che il consumer aggiorni il suo db. È corretto? Intanto continuo ad indagare..... :-) Saluti e grazie, Mirko. ________________________________ Da: Stefanelli Mirko Inviato: lunedì 7 gennaio 2008 15.46 A: '[email protected]' Oggetto: Syncrepl e BDB *core dump* Ciao a tutti, ho il seguente "piccolo" problema e sto cercando di capire quale possa essere la causa. Il problema è la corruzione del db, utilizzo Berkeley DB versione 4.2.52 con le 6 patch (5 del prodotto e una fornita da openldap) e openldap 2.3.39 (stable), nel senso che per qualche oscuro motivo alcuni dei db dei consumer si corrompono e lo slapd va in core. Mi stavo chiedendo se il syncrepl può avere problemi se vi sono cadute della rete e perde la connessione verso il provider? Magari non riesce a terminare la scrittura correttamente? E' possibile che alcune operazioni rimangono in pending? La corruzione del db è stata evidenziata nel momento in cui ho lanciato lo slapindex e dopo un pò che girava anch'esso è andato in core. Per adesso l'unico workaround che ho trovato è quello di importare il db dal master e far ripartire il processo, dopo avere cancellato i files del db corrotto ed i sui files di log. Avete qualche idea/suggerimento a riguardo? Saluti, Mirko.
_______________________________________________ OpenLDAP mailing list [email protected] https://www.sys-net.it/mailman/listinfo/openldap
