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 <bauerman@xxxxxxxxxxxxxxxxxx> --- man2/getrlimit.2 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man2/getrlimit.2 b/man2/getrlimit.2 index 84f04d695ea2..f2c5297526d7 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. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
