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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390