Package: python3.5 Version: 3.5.1-11 Severity: important I just debugged the adt-virt-qemu failure with python 3.5.1-11 and tracked it down to python3.5 hanging for a long time when it gets called before the kernel initializes its RNG (which can take a minute in VMs which have low entropy sources).
With 3.5.1-10:
$ strace -e getrandom python3 -c 'True'
+++ exited with 0 +++
With -11:
$ strace -e getrandom python3 -c 'True'
getrandom("\300\0209\26&v\232\264\325\217\322\303:]\30\212Q\314\244\257t%\206\"",
24, 0) = 24
+++ exited with 0 +++
When you do this with -11 right after booting a VM, the getrandom()
can block for a long time, until the kernel initializes its random
pool:
11:21:36.118034
getrandom("/V#\200^O*HD+D_\32\345\223M\205a\336/\36x\335\246", 24, 0) = 24
11:21:57.939999 ioctl(0, TCGETS, 0x7ffde1d152a0) = -1 ENOTTY (Inappropriate
ioctl for device)
[ 1.549882] [TTM] Initializing DMA pool allocator
[ 39.586483] random: nonblocking pool is initialized
(Note the time stamps in the strace in the first paragraph)
This is really unfriendly -- it essentially means that you stop being
able to use python3 early in the boot process or even early after
booting. It would be better to initialize that random stuff lazily,
until/if things actually need it.
In the diff between -10 and -11 I do seem some getrandom() fixes to
supply the correct buffer size (but that should be irrelevant as in
-10 getrandom() wasn't called in the first place), and a new call
which should apply to Solaris only (#ifdef sun), so it's not entirely
clear where that comes from or how to work around it.
It's very likely that this is the same cause as for #821877, but the
description of that is both completely different and also very vague,
so I file this separately for now.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: PGP signature
