On So, 15.09.19 09:07, Willy Tarreau (w@xxxxxx) wrote: > > That code can finish 5h after boot, it's entirely fine with this > > specific usecase. > > > > Again: we don't delay "the boot" for this. We just delay "writing a > > new seed to disk" for this. And if that is 5h later, then that's > > totally fine, because in the meantime it's just one bg process more that > > hangs around waiting to do what it needs to do. > > Didn't you say it could also happen when using encrypted swap ? If so > I suspect this could happen very early during boot, before any services > may be started ? Depends on the deps, and what options are used in /etc/crypttab. If people hard rely on swap to be enabled for boot to proceed and also use one-time passwords from /dev/urandom they better provide some form of hw rng, too. Otherwise the boot will block, yes. Basically, just add "nofail" to a line in /etc/crypttab, and the entry will be activated at boot, but we won't delay boot for it. It's going to be activated as soon as the deps are fulfilled (and thus the pool initialized), but that may well be 5h after boot, and that's totally OK as long as nothing else hard depends on it. Lennart -- Lennart Poettering, Berlin
