docs: renice(1): Remove obsolete BUGS text

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@gmail.com>
Signed-off-by: Karel Zak <kzak@redhat.com>

diff --git a/sys-utils/renice.1 b/sys-utils/renice.1
index 36e6a5579f4393069bbb3129924f41dc97c8a17e..c4b6834d5ca1b048311fac5541d1de628f3e83b8 100644 (file)
--- a/sys-utils/renice.1
+++ b/sys-utils/renice.1
@@ -106,11 +106,6 @@ to map user names to user IDs
 .BR nice (1),
 .BR getpriority (2),
 .BR setpriority (2)
-.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 systemcall
-interface to set nice values is.  Thus causes renice to report bogus previous
-nice values.
 .SH HISTORY
 The
 .B renice