1RENICE(1P) POSIX Programmer's Manual RENICE(1P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 renice - set nice values of running processes
13
15 renice -n increment [-g | -p | -u] ID ...
16
18 The renice utility shall request that the nice values (see the Base
19 Definitions volume of IEEE Std 1003.1-2001, Section 3.239, Nice Value)
20 of one or more running processes be changed. By default, the applica‐
21 ble processes are specified by their process IDs. When a process group
22 is specified (see -g), the request shall apply to all processes in the
23 process group.
24 The nice value shall be bounded in an implementation-defined manner.
26 If the requested increment would raise or lower the nice value of the
27 executed utility beyond implementation-defined limits, then the limit
28 whose value was exceeded shall be used.
29 When a user is reniced, the request applies to all processes whose
31 saved set-user-ID matches the user ID corresponding to the user.
32 Regardless of which options are supplied or any other factor, renice
34 shall not alter the nice values of any process unless the user request‐
35 ing such a change has appropriate privileges to do so for the specified
36 process. If the user lacks appropriate privileges to perform the
37 requested action, the utility shall return an error status.
38 The saved set-user-ID of the user's process shall be checked instead of
40 its effective user ID when renice attempts to determine the user ID of
41 the process in order to determine whether the user has appropriate
42 privileges.
43
45 The renice utility shall conform to the Base Definitions volume of
46 IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines.
47 The following options shall be supported:
49 -g Interpret all operands as unsigned decimal integer process group
51 IDs.
52 -n increment
54 Specify how the nice value of the specified process or processes
55 is to be adjusted. The increment option-argument is a positive
56 or negative decimal integer that shall be used to modify the
57 nice value of the specified process or processes.
58 Positive increment values shall cause a lower nice value. Negative
60 increment values may require appropriate privileges and shall cause a
61 higher nice value.
62 -p Interpret all operands as unsigned decimal integer process IDs.
64 The -p option is the default if no options are specified.
65 -u Interpret all operands as users. If a user exists with a user
67 name equal to the operand, then the user ID of that user is used
68 in further processing. Otherwise, if the operand represents an
69 unsigned decimal integer, it shall be used as the numeric user
70 ID of the user.
71
74 The following operands shall be supported:
75 ID A process ID, process group ID, or user name/user ID, depending
77 on the option selected.
78
81 Not used.
82
84 None.
85
87 The following environment variables shall affect the execution of
88 renice:
89 LANG Provide a default value for the internationalization variables
91 that are unset or null. (See the Base Definitions volume of
92 IEEE Std 1003.1-2001, Section 8.2, Internationalization Vari‐
93 ables for the precedence of internationalization variables used
94 to determine the values of locale categories.)
95 LC_ALL If set to a non-empty string value, override the values of all
97 the other internationalization variables.
98 LC_CTYPE
100 Determine the locale for the interpretation of sequences of
101 bytes of text data as characters (for example, single-byte as
102 opposed to multi-byte characters in arguments).
103 LC_MESSAGES
105 Determine the locale that should be used to affect the format
106 and contents of diagnostic messages written to standard error.
107 NLSPATH
109 Determine the location of message catalogs for the processing of
110 LC_MESSAGES .
111
114 Default.
115
117 Not used.
118
120 The standard error shall be used only for diagnostic messages.
121
123 None.
124
126 None.
127
129 The following exit values shall be returned:
130 0 Successful completion.
132 >0 An error occurred.
134
137 Default.
138 The following sections are informative.
140
142 None.
143
145 1. Adjust the nice value so that process IDs 987 and 32 would have a
146 lower nice value:
147 renice -n 5 -p 987 32
150 2. Adjust the nice value so that group IDs 324 and 76 would have a
152 higher nice value, if the user has the appropriate privileges to do
153 so:
154 renice -n -4 -g 324 76
157 3. Adjust the nice value so that numeric user ID 8 and user sas would
159 have a lower nice value:
160 renice -n 4 -u 8 sas
163 Useful nice value increments on historical systems include 19 or 20
165 (the affected processes run only when nothing else in the system
166 attempts to run) and any negative number (to make processes run
167 faster).
168
170 The gid, pid, and user specifications do not fit either the definition
171 of operand or option-argument. However, for clarity, they have been
172 included in the OPTIONS section, rather than the OPERANDS section.
173 The definition of nice value is not intended to suggest that all pro‐
175 cesses in a system have priorities that are comparable. Scheduling
176 policy extensions such as the realtime priorities in the System Inter‐
177 faces volume of IEEE Std 1003.1-2001 make the notion of a single under‐
178 lying priority for all scheduling policies problematic. Some implemen‐
179 tations may implement the nice-related features to affect all processes
180 on the system, others to affect just the general time-sharing activi‐
181 ties implied by this volume of IEEE Std 1003.1-2001, and others may
182 have no effect at all. Because of the use of "implementation-defined"
183 in nice and renice, a wide range of implementation strategies are pos‐
184 sible.
185 Originally, this utility was written in the historical manner, using
187 the term "nice value". This was always a point of concern with users
188 because it was never intuitively obvious what this meant. With a newer
189 version of renice, which used the term "system scheduling priority", it
190 was hoped that novice users could better understand what this utility
191 was meant to do. Also, it would be easier to document what the utility
192 was meant to do. Unfortunately, the addition of the POSIX realtime
193 scheduling capabilities introduced the concepts of process and thread
194 scheduling priorities that were totally unaffected by the nice/ renice
195 utilities or the nice()/ setpriority() functions. Continuing to use the
196 term "system scheduling priority'' would have incorrectly suggested
197 that these utilities and functions were indeed affecting these realtime
198 priorities. It was decided to revert to the historical term "nice
199 value" to reference this unrelated process attribute.
200 Although this utility has use by system administrators (and in fact
202 appears in the system administration portion of the BSD documentation),
203 the standard developers considered that it was very useful for individ‐
204 ual end users to control their own processes.
205
207 None.
208
210 nice()
211
213 Portions of this text are reprinted and reproduced in electronic form
214 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
215 -- Portable Operating System Interface (POSIX), The Open Group Base
216 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
217 Electrical and Electronics Engineers, Inc and The Open Group. In the
218 event of any discrepancy between this version and the original IEEE and
219 The Open Group Standard, the original IEEE and The Open Group Standard
220 is the referee document. The original Standard can be obtained online
221 at http://www.opengroup.org/unix/online.html .
222IEEE/The Open Group 2003 RENICE(1P)