On Mon, Mar 31, 2025 at 06:31:30AM +0000, Windl, Ulrich wrote: > Ondřej, > > I must admit that I loaded the same LDIF using -w on both servers > (whenever the automatic sync would not work, or the server would not > start). However the LDIFs should have contained some entryCSN for each > entry, and if I had edited an entry, incremented the entryCSN "a bit". > In my understanding the contextCSN would be adjusted to be the latest > entryCSN, right?
Hi Ulrich, `-w` will replace all CSNs from the LDIF with freshly generated ones, that's why I say you should only do that on a manual reload on *one* replica and then use their DB to reload everyone else with. You are rewriting the whole DB from scratch after all. > Still I'm surprised that some "Odd" CSN would cause a huge memory > allocation that causes the server to crash. Until it happens again, > I'll ignore it for now (as I have much more work to do) I'm not saying for sure it's causing it, very likely a bug but then not much we can do looking at that stack trace. Unless you provide concrete steps to reproduce the issue (preferable), usually logs + a full backtrace with debugging info available is the minimum we'd need to start investigating a crash... What I was saying is that what you did was very likely to cause a painful desync later, especially with cn=config and if you're likely to do this sort of thing again and again. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
