Hi, I found a couple of certain packages suffering from build stalls until the build is aborted. When retrying the build many times, it eventually succeeds (most probably due to building on a build host, that doesn't suffer from this issue for some reason). While occasionally observable with all (x86) targets, it is reproducible with a probability near 100 with old distributions like 13.2 (yeah, lame, I know..). Given, that BS attempts to be target agnostic, let's take this as a chance to determine and avoid this pitfall in the future for all kinds of targets. Often, these stalls happen after a python3 sphinx-build is executed. Another regular pattern for these stalls is during py.test3 runs. I was able to track this issue down with "osc build --vm-type=kvm" for a 13.2 build and running build-sphinx with strace: [ 11s] + cat /proc/sys/kernel/random/entropy_avail [ 11s] 0 [ 11s] + PYTHONPATH=/home/abuild/rpmbuild/BUILDROOT/python-pyOpenSSL-18.0.0-0.x86_64/usr/lib/python3.7/site-packages [ 11s] + strace -fttvs4096 -o.trc python3 setup.py build_sphinx [ 11s] running build_sphinx [ 11s] creating /home/abuild/rpmbuild/BUILD/pyOpenSSL-18.0.0/build/sphinx [ 11s] creating /home/abuild/rpmbuild/BUILD/pyOpenSSL-18.0.0/build/sphinx/doctrees [ 11s] creating /home/abuild/rpmbuild/BUILD/pyOpenSSL-18.0.0/build/sphinx/html [ 11s] Running Sphinx v1.7.6 where the trace log ends with: 1125 20:07:26.812659 open("/dev/random", O_RDONLY) = 4 1125 20:07:26.812741 fcntl(4, F_GETFD) = 0 1125 20:07:26.812765 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 1125 20:07:26.812783 poll([{fd=4, events=POLLIN}], 1, 4294967295 As far as I can tell, the /dev/random reads are initiated from python3 (v3.7.2). No idea, why it isn't using /dev/urandom, though. Since KVM IS started with some rng mechanics in place: /usr/bin/qemu-kvm -nodefaults -no-reboot -nographic -vga none -cpu host \ -object rng-random,filename=/dev/random,id=rng0 -device virtio-rng-pci,rng=rng0 [...] I wonder, why it doesn't appear inside the build: /proc/sys/kernel/random/entropy_avail is 0 here. In an attempt to fix this issue, I added this to the prjconf: Preinstall: haveged Runscripts: haveged but that doesn't change the picture. So the question boils down to: How do I get (enough) entropy into the building KVM locally and in the BS? Thanks, Pete https://build.opensuse.org/package/show/home:frispete:python/python-pyOpenSS... Local system uses Linux 4.20.12, qemu-kvm-3.1.0, osc-0.164.2, build-20190123, python 3.7.2 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org