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,
openldap-technical@openldap.org