[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9686307.bD1gDyONvH@merkaba>
Date: Sun, 15 Sep 2019 00:05:24 +0200
From: Martin Steigerwald <martin@...htvoll.de>
To: "Ahmed S. Darwish" <darwish.07@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Theodore Y. Ts'o" <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
William Jon McCann <mccann@....edu>,
"Alexander E. Patrakov" <patrakov@...il.com>,
zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
Lennart Poettering <lennart@...ttering.net>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8
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=@...tlibexecdir@...stemd-random-seed load
> ExecStop=@...tlibexecdir@...stemd-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
Powered by blists - more mailing lists