Am 13.12.2018 um 21:44 schrieb David Boreham:
It could be something like : the VM host changed (guest may have
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
We are on Version 184.108.40.206-4 - I think there isn't this autoconfig
feature yet. Am I right? We are on debian jessie since it's part of an
size caches that are appropriate in size) and b) strace the process
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 220.127.116.11-2 dirsrv starts again. Migration of the
databases and config worked.
Hm, I'll look deeper into tomorrow.
Thanks a lot for now!