From 2acd68e32ae494081440704dda820f79b26cd022 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Fri, 9 Dec 2016 13:32:34 +0100 Subject: 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 Signed-off-by: Karel Zak --- sys-utils/renice.1 | 5 ----- 1 file changed, 5 deletions(-) (limited to 'sys-utils/renice.1') diff --git a/sys-utils/renice.1 b/sys-utils/renice.1 index 36e6a5579..c4b6834d5 100644 --- 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 -- cgit v1.2.3-55-g7522