getrandom() before forking daemon is blocking init system
Hello
When booting from a slow machine, I can observe dovecot blocking the whole boot process. I traced it down to the getrandom() system call in lib/randgen.c, which blocks until the random number generator is initialized (dmesg "random: crng init done"). This can take up to three minutes (!) on my machine, as there is not much entropy available (no hardware RNG, network VPN is also waiting for random).
Unfortunately dovecot calls getrandom() before forking a daemon, which as a consequence blocks the whole init process (OpenRC on Gentoo Linux).
I believe this behavior has changed in kernel 4.14:
Quoting getrandom(2): "If the urandom source has not yet been initialized, then getrandom() will block, unless GRND_NONBLOCK is specified in flags."
Dovecot: 2.3.4.1 (f79e8e7e4)
Linux: 4.19.26-gentoo #2 SMP Thu Feb 28 20:30:23 CET 2019 x86_64 AMD G-T40E Processor AuthenticAMD GNU/Linux
Regards,
Axel
On Tue, Mar 05, 2019 at 05:39:28PM +0100, Axel Burri via dovecot wrote:
Hello
When booting from a slow machine, I can observe dovecot blocking the whole boot process. I traced it down to the getrandom() system call in lib/randgen.c, which blocks until the random number generator is initialized (dmesg "random: crng init done"). This can take up to three minutes (!) on my machine, as there is not much entropy available (no hardware RNG, network VPN is also waiting for random).
Unfortunately dovecot calls getrandom() before forking a daemon, which as a consequence blocks the whole init process (OpenRC on Gentoo Linux).
I believe this behavior has changed in kernel 4.14:
Quoting getrandom(2): "If the urandom source has not yet been initialized, then getrandom() will block, unless GRND_NONBLOCK is specified in flags."
Dovecot: 2.3.4.1 (f79e8e7e4)
Linux: 4.19.26-gentoo #2 SMP Thu Feb 28 20:30:23 CET 2019 x86_64 AMD G-T40E Processor AuthenticAMD GNU/Linux
Regards,
Axel
It should either block or fail to start. I personally like the idea of blocking so it starts up successfully.
Have you tried installing an entropy daemon or something to provide more entropy? I've seen people suggest haveged before.
On a side note.. I thought you want to call getrandom() after forking otherwise all children have the same rng sequence.
On 05 March 2019 at 18:51 William Taylor via dovecot dovecot@dovecot.org wrote:
On Tue, Mar 05, 2019 at 05:39:28PM +0100, Axel Burri via dovecot wrote:
Hello
When booting from a slow machine, I can observe dovecot blocking the whole boot process. I traced it down to the getrandom() system call in lib/randgen.c, which blocks until the random number generator is initialized (dmesg "random: crng init done"). This can take up to three minutes (!) on my machine, as there is not much entropy available (no hardware RNG, network VPN is also waiting for random).
Unfortunately dovecot calls getrandom() before forking a daemon, which as a consequence blocks the whole init process (OpenRC on Gentoo Linux).
I believe this behavior has changed in kernel 4.14:
Quoting getrandom(2): "If the urandom source has not yet been initialized, then getrandom() will block, unless GRND_NONBLOCK is specified in flags."
Dovecot: 2.3.4.1 (f79e8e7e4)
Linux: 4.19.26-gentoo #2 SMP Thu Feb 28 20:30:23 CET 2019 x86_64 AMD G-T40E Processor AuthenticAMD GNU/Linux
Regards,
Axel
It should either block or fail to start. I personally like the idea of blocking so it starts up successfully.
Have you tried installing an entropy daemon or something to provide more entropy? I've seen people suggest haveged before.
On a side note.. I thought you want to call getrandom() after forking otherwise all children have the same rng sequence.
Entropy daemon is very recommended for your server in any case, otherwise you'll have lots of trouble with SSL.
Aki
On 05/03/2019 17.53, Aki Tuomi wrote:
On 05 March 2019 at 18:51 William Taylor via dovecot dovecot@dovecot.org wrote:
On Tue, Mar 05, 2019 at 05:39:28PM +0100, Axel Burri via dovecot wrote:
Hello
When booting from a slow machine, I can observe dovecot blocking the whole boot process. I traced it down to the getrandom() system call in lib/randgen.c, which blocks until the random number generator is initialized (dmesg "random: crng init done"). This can take up to three minutes (!) on my machine, as there is not much entropy available (no hardware RNG, network VPN is also waiting for random).
Unfortunately dovecot calls getrandom() before forking a daemon, which as a consequence blocks the whole init process (OpenRC on Gentoo Linux).
I believe this behavior has changed in kernel 4.14:
Quoting getrandom(2): "If the urandom source has not yet been initialized, then getrandom() will block, unless GRND_NONBLOCK is specified in flags."
Dovecot: 2.3.4.1 (f79e8e7e4)
Linux: 4.19.26-gentoo #2 SMP Thu Feb 28 20:30:23 CET 2019 x86_64 AMD G-T40E Processor AuthenticAMD GNU/Linux
Regards,
Axel
It should either block or fail to start. I personally like the idea of blocking so it starts up successfully.
Usually I would agree, but the problem here is that it blocks the init process, which is very bad (e.g. without tweaking, vital services like sshd started later in the boot process, all waiting for dovecot).
Have you tried installing an entropy daemon or something to provide more entropy? I've seen people suggest haveged before.
For now, I run a filesystem scrub in the boot process, which already provides quite some entropy (presumably by disk interrupts). "haveged" would probably also help, but I'd like not to tweak my RNG too much, as bad randomness can weaken crypto a lot.
On a side note.. I thought you want to call getrandom() after forking otherwise all children have the same rng sequence.
I'm not saying that I know how this is done correctly. All I know it that other daemons using SSL (and thus requiring random) also start without blocking the init process.
Entropy daemon is very recommended for your server in any case, otherwise you'll have lots of trouble with SSL.
Aki
participants (3)
-
Aki Tuomi
-
Axel Burri
-
William Taylor