On Mon, Oct 29, 2018 at 07:11:17PM +0100, Michael Biebl wrote: > On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx <k...@roeckx.be> wrote: > > reassign 912087 openssh-server,systemd > > thanks > > > > On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote: > > > On Mon, Oct 29, 2018 at 12:28:15AM +0000, Colin Watson wrote: > > > > Reassigning to OpenSSL - could the OpenSSL maintainers please have a > > > > look and advise what's best to do? (See the start of the bug, reporting > > > > a delay of more than one minute in system boot in some cases, mainly > > > > waiting for sshd to start.) > > > > > > The biggest change related to this is that we know use > > > getrandom()/getentropy() on kernels that have it, so kernels > > > >= 3.17. And the kernel using that interface doesn't return random > > > numbers until it has been initialized. > > > > > > Something should be initializing the kernel with random data from > > > the previous boot. This used to be done by /etc/init.d/urandom, > > > but I'm not sure if that's still used. This should be done as > > > early as possible during the boot not to cause such problems. You > > > should look into when during the boot process the kernel gets this > > > random data. > > > > So I believe this is not an openssl issue, but something in the > > order that the kernel's RNG is initialized and openssh is started. > > Potentionally the RNG isn't initialized at all and you actually > > have to wait for the kernel to get it's random data from the slow > > way. > > The service is called systemd-random-seed.service and stores the random > seed during shutdown and restores it during boot. Pretty much as urandom > did under sysvinit. > This service is run in sysinit.target, ssh.service is started in > multi-user.target, which is ordered after sysvinit.target.
Clearly it's not working for the person reporting this issue, or we wouldn't have this discussion. Kurt