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/systemd-random-seed.service.in > +++ b/units/systemd-random-seed.service.in > @@ -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 https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#entropy-starvation [2] Openssh taking minutes to become available, booting takes half an hour ... because your server waits for a few bytes of randomness https://daniel-lange.com/archives/152-hello-buster.html Thanks, -- Martin
