Hi Gustavo, On Thu, Aug 16, 2018 at 01:09:39PM +0000, Gustavo Scalet wrote:
Package: chrony Version: 3.3-2 Severity: important Tags: patchDear Maintainer, When trying out buster using fai-cloud-image scripts on Google cloud I noticed that system took around 180 seconds to boot rather than 15 seconds (stretch).
By the way, in the systemd world, the default timeout for starting a unit is 90s. So I assume that chrony just fail to start before enough entropy has been gathered‽
After investigating, I detected it was a lack of entropy early on system startup that caused chrony to be blocked when calling getrandom(). That is an issue being reported on different projects[1][2] but I didn't see anyone reporting it for chrony at the moment. (Maybe the lack of entropy was not spotted when using buster outside of cloud providers?)
Sure, generating entropy on a VM can be quite problematic. To prevent entropy starvation in guests, I make use of VirtIO RNG which is probably the reason why I’m not affected by this issue.
The upstream project is patched already[3], but there is no new release for the moment. I contacted the maintainer[4] and there should be a new release in the following month that would contain that fix[5]. I chose to report this bug and provide a patch in order to avoid others facing this issue which is not so trivial to understand what is going on.
I was aware of this issue but I refrained from backporting 7c5bd948bb7e (util: fall back to reading /dev/urandom when getrandom() blocks) as like you said, nobody sent me a bug report, neither publicly nor privately, about this issue. However your bug report clearly shows that this problem has to be taken seriously. I’ll work on this on the weekend, hope that’s ok?
Cheers, Vincent
signature.asc
Description: PGP signature
