Re: Linux 5.3-rc8

From: Martin Steigerwald
Date: Sat Sep 14 2019 - 18:15:18 EST

Ahmed S. Darwish - 14.09.19, 23:11:26 CEST:
> > Yeah, the above is yet another example of completely broken garbage.
> >
> > You can't just wait and block at boot. That is simply 100%
> > unacceptable, and always has been, exactly because that may
> > potentially mean waiting forever since you didn't do anything that
> > actually is likely to add any entropy.
> ACK, the systemd commit which introduced that code also does:
> => 26ded5570994 (random-seed: rework systemd-random-seed.service..)
> [...]
> --- a/units/
> +++ b/units/
> @@ -22,4 +22,9 @@ Type=oneshot
> RemainAfterExit=yes
> ExecStart=@rootlibexecdir@/systemd-random-seed load
> ExecStop=@rootlibexecdir@/systemd-random-seed save
> -TimeoutSec=30s
> +
> +# This service waits until the kernel's entropy pool is
> +# initialized, and may be used as ordering barrier for service
> +# that require an initialized entropy pool. Since initialization
> +# can take a while on entropy-starved systems, let's increase the
> +# time-out substantially here.
> +TimeoutSec=10min
> This 10min wait thing is really broken... it's basically "forever".

I am so happy to use Sysvinit on my systems again. Depending on entropy
for just booting a machine is broken¹.

Of course regenerating SSH keys on boot, probably due to cloud-init
replacing the old key after a VM has been cloned from template, may
still be a challenge to handle well². I'd probably replace SSH keys in
the background and restart the service then, but this may lead to
spurious man in the middle warnings.

[1] Debian Buster release notes: 5.1.4. Daemons fail to start or system
appears to hang during boot

[2] Openssh taking minutes to become available, booting takes half an
hour ... because your server waits for a few bytes of randomness