From 4a63f626b5784529f849d1cc27949eee55a23033 Mon Sep 17 00:00:00 2001 From: Thiago Jung Bauermann Date: Fri, 1 Sep 2017 17:27:43 -0300 Subject: [PATCH] getrlimit.2: Mention unit used by RLIMIT_CORE and RLIMIT_FSIZE It would have been obvious that these limits are in bytes, except that "ulimit -a" in at least bash, dash and zsh says that they're in blocks. This confused me, so I had to check the kernel source code. My understanding is that they are indeed in bytes, so mention this information in the man page. Signed-off-by: Thiago Jung Bauermann Signed-off-by: Michael Kerrisk --- man2/getrlimit.2 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man2/getrlimit.2 b/man2/getrlimit.2 index 84f04d695..f2c529752 100644 --- a/man2/getrlimit.2 +++ b/man2/getrlimit.2 @@ -150,7 +150,7 @@ This is the maximum size of a .I core file (see .BR core (5)) -that the process may dump. +in bytes that the process may dump. When 0 no core dump files are created. When nonzero, larger dumps are truncated to this size. .TP @@ -187,7 +187,7 @@ which fail with the error upon encountering the soft limit of this resource. .TP .B RLIMIT_FSIZE -This is the maximum size of files that the process may create. +This is the maximum size in bytes of files that the process may create. Attempts to extend a file beyond this limit result in delivery of a .B SIGXFSZ signal.