Re: Unbound 1.7.1 failing on some kvm servers

>>>>> James Cloos via Unbound-users <unbound-users@unbound.net> writes: > I have a number of kvm instances running debian where unbound 1.7.1 > fails. An LD_PRELOAD lib which implments getentropy(3) via read(3)ing urandom(4) solved the bug. Unbound *always* should f

Unbound 1.7.1 failing on some kvm servers

I have a number of kvm instances running debian where unbound 1.7.1 fails. Many of these instances run whichever kernel was current when I first leased them, and do not support newer kernels. (Others look on the fs for a kernel to kexec, but not all do.) Debian of course compiles unbound on a

Re: High latency setting optimization

> "FL" == Florian Lohoff via Unbound-users > writes: FL> We are running multiple unbound caches behind very long latency FL> sat links. We are seeing RTT of at least 1000ms. ... FL> I have already seen jostle-timeout. I am pretty shure prefetching FL> has a

Re: Unbound 1.7.1 failing on some kvm servers

> "WW" == W C A Wijngaards via Unbound-users > writes: >> Unbound *always* should fall back to urandom(4) when getentropy(3) >> results in ENOSYS, even when compiled against a kernel which advertizes >> support for getrandom(2). WW> But Unbound does that! WW> It falls back to that when

Re: Unbound 1.7.1 failing on some kvm servers

> "WW" == W C A Wijngaards writes: >> Once the call to glibc's genentropy(3) fails, it immediately sends a >> SIGKILL. WW> But in your strace you have a call to getrandom() that fails. compat/getentropy_linux.c calls genentropy(3) which calls getrandom(2). >> Indeed,