On 27.09.19 10:47, Johan Schelling wrote:
> I did some additional testing yesterday using gdb and strace….
>
> gbd didn’t return any useful information, but that might also be due to my
> lack of gdb experience. Running strace resulted in the following:
>
> ...
> clock_gettime(CLOCK_MONOTONIC, {207116, 975055264}) = 0
> clock_gettime(CLOCK_MONOTONIC, {207116, 975185579}) = 0
> mmap(0xc420200000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xc420200000
> mmap(0xc41ffe8000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xc41ffe8000
> clock_gettime(CLOCK_MONOTONIC, {207116, 975325872}) = 0
> clock_gettime(CLOCK_MONOTONIC, {207116, 975713954}) = 0
> mmap(0xc420300000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xc420300000
> mmap(0xc41ffe0000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xc41ffe0000
> clock_gettime(CLOCK_MONOTONIC, {207116, 977430825}) = 0
> getrandom(
>
> Doesn’t matter whether I use docker 1.13 or docker-ce 18, on the Clefos75
> guest the daemon process hangs on the getrandom system call..
>
> When I do the same on an Ubuntu 16.04 guest (where the daemon starts and runs
> without any issues) the strace shows the same getrandom call which executes
> successfully:
>
> ...
> futex(0xc420098948, FUTEX_WAKE, 1) = 1
> futex(0xc42005e948, FUTEX_WAKE, 1) = 1
> futex(0xc420098948, FUTEX_WAKE, 1) = 1
> futex(0xc420098948, FUTEX_WAKE, 1) = 1
> getrandom("h\"\277\352\376\262(\344", 8, 0) = 8
> clock_gettime(CLOCK_REALTIME, {1569355392, 476405161}) = 0
> clock_gettime(CLOCK_MONOTONIC, {2337380, 47849415}) = 0
> clock_gettime(CLOCK_REALTIME, {1569355392, 477070655}) = 0
> clock_gettime(CLOCK_MONOTONIC, {2337380, 48519415}) = 0
> clock_gettime(CLOCK_REALTIME, {1569355392, 477339454}) = 0
> clock_gettime(CLOCK_MONOTONIC, {2337380, 48781970}) = 0
> ...
>
> Both the Clefos and Ubuntu guests are running in KVM.
> On the Clefos guest I have running in zVM the getrandom call executes
> successfully……
>
> Reading up on the issue…. i found this: "When the entropy pool is empty,
> reads from /dev/random will block until additional environmental noise is
> gathered."
> Running “cat /dev/random” on the clefos guest actually freezes…. Doing
> the same on the Ubuntu guest does return data as does running the command on
> the clefos guest in zVM . So I feel that that’s where there problem is.
> Any other insights?
That makes sense. Can you maybe add a virtio-rng device to those guests
and install an rngd daemon in the guest that feeds the entropy from
/dev/hwrng back into the kernel entropy?
PS: some kernel versions had bugs where they did not get enough entropy from
disk and network activity. Maybe thats something to look at for Neale.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
