Am 13.12.2018 um 21:44 schrieb David Boreham: > It could be something like : the VM host changed (guest may have been > migrated live) such that the physical memory is much larger. This > combined with situation I mentioned earlier where the cache size is > computed from the host physical memory not the guest might explain the > symptoms. I'd definitely look at a) cache auto size (should be printed Nothing of this happened. The host machine didn't change for month. No migration. Everything as before. > in the log somewhere, and you can just disable it by configuring fixed We are on Version 1.3.3.5-4 - I think there isn't this autoconfig feature yet. Am I right? We are on debian jessie since it's part of an kolab environment. > size caches that are appropriate in size) and b) strace the process to > see why it is failing -- for example you may see an sbrk() call for a > zillion bytes or an mmap() call for a huge region, that fails. I think > strace might have an option to log only failing syscalls. Before struggling with this, I tried upgrading 389-ds in a snapshot: After upgrade to 1.3.5.17-2 dirsrv starts again. Migration of the databases and config worked. Hm, I'll look deeper into tomorrow. Thanks a lot for now! Regards Jan _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
