"I don't think systemd is doing anything wrong here, and we really shouldn't change anything." -- Lennart Poettering, 2016-09-18, https://github.com/systemd/sys

"I don't think systemd is doing anything wrong here, and we really shouldn't change anything." -- Lennart Poettering, 2016-09-18, https://github.com/systemd/systemd/issues/4167#issuecomment-247835419 https://github.com/systemd/systemd/issues/4167#issuecomment-... The bug report also explains what systemd is doing here. "systemd starts allocating those hashtables very very early on, before any process is forked off... It's par tof the initialization scheme of systemd really. Hence there's basically nothing else going on in the system, execept what is done by the kernel itself", -- Lennart Poettering, 2016-05-05, https://lists.freedesktop.org/archives/systemd-devel/2014-May/019037.html https://lists.freedesktop.org/archives/systemd-devel/2014-Ma... "moving that blocking behavior to /dev/urandom simply does not work. The system does not boot. The reason to this issue is actually quite simple. The init process of systemd reads /dev/urandom for whatever purpose. Now, when /dev/urandom blocks during boot, systemd will be blocked too." -- Stephan Mueller, 2016-10-22, https://lkml.org/lkml/2016/10/21/982 https://lkml.org/lkml/2016/10/21/982