renice -n increment [-g | -p | -u] ID ...
The renice utility shall request that the nice values (see the Base Definitions volume of IEEE Std 1003.1-2001, Section 3.239, Nice Value) of one or more running processes be changed. By default, the applicable processes are specified by their process IDs. When a process group is specified (see -g), the request shall apply to all processes in the process group.
The nice value shall be bounded in an implementation-defined manner. If the requested increment would raise or lower the nice value of the executed utility beyond implementation-defined limits, then the limit whose value was exceeded shall be used.
When a user is reniced, the request applies to all processes whose saved set-user-ID matches the user ID corresponding to the user.
Regardless of which options are supplied or any other factor, renice shall not alter the nice values of any process unless the user requesting such a change has appropriate privileges to do so for the specified process. If the user lacks appropriate privileges to perform the requested action, the utility shall return an error status.
The saved set-user-ID of the user's process shall be checked instead of its effective user ID when renice attempts to determine the user ID of the process in order to determine whether the user has appropriate privileges.
The renice utility shall conform to the Base Definitions volume of IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
The following options shall be supported:
Positive increment values shall cause a lower nice value. Negative increment values may require appropriate privileges and shall cause a higher nice value.
The following operands shall be supported:
The following environment variables shall affect the execution of renice:
The standard error shall be used only for diagnostic messages.
The following exit values shall be returned:
Default.
The following sections are informative.
renice -n 5 -p 987 32
renice -n -4 -g 324 76
renice -n 4 -u 8 sas
Useful nice value increments on historical systems include 19 or 20 (the affected processes run only when nothing else in the system attempts to run) and any negative number (to make processes run faster).
The gid, pid, and user specifications do not fit either the definition of operand or option-argument. However, for clarity, they have been included in the OPTIONS section, rather than the OPERANDS section.
The definition of nice value is not intended to suggest that all processes in a system have priorities that are comparable. Scheduling policy extensions such as the realtime priorities in the System Interfaces volume of IEEE Std 1003.1-2001 make the notion of a single underlying priority for all scheduling policies problematic. Some implementations may implement the nice-related features to affect all processes on the system, others to affect just the general time-sharing activities implied by this volume of IEEE Std 1003.1-2001, and others may have no effect at all. Because of the use of "implementation-defined" in nice and renice, a wide range of implementation strategies are possible.
Originally, this utility was written in the historical manner, using the term "nice value". This was always a point of concern with users because it was never intuitively obvious what this meant. With a newer version of renice, which used the term "system scheduling priority", it was hoped that novice users could better understand what this utility was meant to do. Also, it would be easier to document what the utility was meant to do. Unfortunately, the addition of the POSIX realtime scheduling capabilities introduced the concepts of process and thread scheduling priorities that were totally unaffected by the nice/ renice utilities or the nice()/ setpriority() functions. Continuing to use the term "system scheduling priority'' would have incorrectly suggested that these utilities and functions were indeed affecting these realtime priorities. It was decided to revert to the historical term "nice value" to reference this unrelated process attribute.
Although this utility has use by system administrators (and in fact appears in the system administration portion of the BSD documentation), the standard developers considered that it was very useful for individual end users to control their own processes.