Already at least as far back as util-linux 2.2, renice uses
getpriority(2) to fetch the process's old nice value. Thus,
the "problem" discussed in this BUGS note disappeared long ago.
This is trivially demonstrable:
$ sleep 100 &
[1] 24322
$ renice -n 5 24322
24322 (process ID) old priority 0, new priority 5
$ renice -n 10 24322
24322 (process ID) old priority 5, new priority 10
Rather than trying to explain the ancient problem (20 years old?),
just kill this text.
Signed-off-by: Michael Kerrisk <mtk.man-pages@xxxxxxxxx>
---
sys-utils/renice.1 | 5 -----
1 file changed, 5 deletions(-)
diff --git a/sys-utils/renice.1 b/sys-utils/renice.1
index d37fcf1..5ac8e4b 100644
--- a/sys-utils/renice.1
+++ b/sys-utils/renice.1
@@ -108,11 +108,6 @@ to map user names to user IDs
.BR setpriority (2),
.BR credentials (7),
.BR sched (7)
-.SH BUGS
-The Linux kernel (at least version 2.0.0) and linux libc (at least version
-5.2.18) does not agree entirely on what the specifics of the system call
-interface to set nice values is. Thus causes renice to report bogus previous
-nice values.
.SH HISTORY
The
.B renice
--
2.5.5
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
