From dbf63eed2d40a9840a0c8e066530c7ddaf0f9366 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Thu, 10 Nov 2016 14:37:33 +0100 Subject: [PATCH] random.4: Improve discussion of /dev/urandom, blocking reads, and signals The text currently states that O_NONBLOCK has no effect for /dev/urandom, which is true. It also says that reads from /dev/urandom are nonblocking. This is at the least confusing. If one attempts large reads (say 10MB) from /dev/urandom there is an appreciable delay, and interruption by a signal handler will result in a short read. Amend the text to reflect this. Reviewed-by: Laurent Georget Reviewed-by: Theodore Ts'o Signed-off-by: Michael Kerrisk --- man4/random.4 | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/man4/random.4 b/man4/random.4 index db5d0a2fd..736cbdea9 100644 --- a/man4/random.4 +++ b/man4/random.4 @@ -46,7 +46,6 @@ When read, the .I /dev/urandom device returns random bytes using a pseudorandom number generator seeded from the entropy pool. -Reads from this device are nonblocking. When read during early boot time, this device may return data prior to the entropy pool being initialized. If this is of concern in your application, use @@ -88,8 +87,11 @@ When calling .BR read (2) for the device .IR /dev/urandom , -signals will not be handled until after the requested random bytes -have been generated. +reads of up to 256 bytes will return as many bytes as are requested +and will not be interrupted by a signal handler. +Reads with a buffer over this limit may return less than the +requested number of bytes or fail with the error +.BR EINTR . Since Linux 3.16, .\" commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc