cloud-init hangs on boot as Python waits for sufficient randomness to start
Bug #1584147 reported by
Dan Watkins
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Python |
Fix Released
|
Unknown
|
|||
cloud-images |
Fix Released
|
High
|
Unassigned | ||
python3.5 (Debian) |
Fix Released
|
Unknown
|
|||
python3.5 (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
If Python 3.5 starts before the kernel has initialised its RNG, it will hang[0] until there is sufficient entropy for it to randomise dictionary keys.
As cloud-init uses Python 3.5, this means that cloud-init will hang until this happens (meaning that the instance won't be properly initialised).
I have seen this cause a hang of up to 7 minutes on an OpenStack cloud.
Upstream python bug is issue 26839 [1].
[0] https:/
[1] https:/
Changed in cloud-images: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in python3.5 (Debian): | |
status: | Unknown → Confirmed |
description: | updated |
Changed in python: | |
status: | Unknown → Fix Committed |
Changed in python3.5 (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in python3.5 (Debian): | |
status: | Confirmed → Fix Released |
Changed in python: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
A partial workaround for this is to set PYTHONHASHSEED in the environment of the cloud-init systemd units, which means that Python won't block at _startup_ for randomness.
Unfortunately, importing the "random" module (which, e.g., the tempfile module does) still seems to cause some sort of hang.