1.\" $NetBSD: renice.8,v 1.18 2020/10/23 16:14:40 wiz Exp $ 2.\" 3.\" Copyright (c) 1983, 1991, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. Neither the name of the University nor the names of its contributors 15.\" may be used to endorse or promote products derived from this software 16.\" without specific prior written permission. 17.\" 18.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 21.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" from: @(#)renice.8 8.1 (Berkeley) 6/9/93 31.\" 32.Dd October 22, 2020 33.Dt RENICE 8 34.Os 35.Sh NAME 36.Nm renice 37.Nd alter priority of running processes 38.Sh SYNOPSIS 39.Nm 40.Ar priority 41.Oo 42.Op Fl gpu 43.Ar who ... 44.Oc 45.Ar ... 46.Nm 47.Fl n 48.Ar increment 49.Oo 50.Op Fl gpu 51.Ar who ... 52.Oc 53.Ar ... 54.Sh DESCRIPTION 55.Nm 56alters the 57scheduling priority of one or more running processes. 58The first argument is the new priority to apply, or if 59.Fl n 60is given, the change to make (applied additively) to the priority. 61This argument may be negative. 62(The interpretation of priorities is discussed below.) 63.Pp 64The following 65.Ar who 66parameters name the target processes, as either process IDs, process 67group IDs, or user names. 68The 69.Fl gpu 70options control the interpretation as follows: 71.Bl -tag -width Ds 72.It Fl g 73Interpret 74.Ar who 75parameters as process group ID's. 76.It Fl p 77Interpret 78.Ar who 79parameters as process IDs. 80This is the default. 81.It Fl u 82Interpret 83.Ar who 84parameters as user names. 85.El 86.Pp 87Each 88.Ar who 89parameter is processed separately and updates the priority of the 90processes it names as follows: 91.Bl -tag -width "with Ds" 92.It with Fl g 93All processes in the process group are updated to the selected 94priority. 95If an 96.Ar increment 97is used, the increment is added to the highest priority found among 98the members of the process group prior to the change. 99.It with Fl p 100The named process is updated to the selected priority. 101If an 102.Ar increment 103is used, the increment is added to the process's previous priority. 104.It with Fl u 105All processes belonging to the specified user are updated to the 106selected priority. 107If an 108.Ar increment 109is used, the increment is added to the highest priority found among 110the processes belonging to the user prior to the change. 111.El 112.Pp 113In conventional terminology a 114.Dq high priority 115process receives a lot of CPU time and a 116.Dq low priority 117process receives relatively little. 118.Dq Niceness 119is the inverse concept: a process with a high niceness level receives 120relatively little CPU time. 121It is about the process being nice to the rest of the system, rather 122than the system being nice to the process. 123.Pp 124The numerical priority values accepted by 125.Nm 126are 127.Em called 128priorities but are actually nicenesses. 129They range from 130.Dv PRIO_MIN 131(\-20) 132to 133.Dv PRIO_MAX 134(20). 135.Dv PRIO_MIN 136is the highest priority, lowest niceness, and receives the most CPU 137time. 138.Dv PRIO_MAX 139is the lowest priority, highest niceness, and receives the least CPU 140time. 141This is confusing but enshrined in historical practice and standards. 142If in doubt, check with 143.Xr ps 1 : 144processes running with elevated priority (getting more CPU time) 145include 146.Sq < 147in the FLAGS column; processes running with reduced priority 148(getting less CPU time) show 149.Sq N 150for 151.Dq nice 152in FLAGS. 153The default priority is 0. 154.Pp 155At priority 20, processes will specifically run only when nothing else 156wants to. 157.Pp 158Users other than the super-user may only alter the priority of 159processes they own, 160and only by increasing the niceness. 161(This prevents overriding administrative fiats.) 162The super-user 163may alter the priority of any process to any legal value. 164.Sh FILES 165.Bl -tag -width /etc/passwd -compact 166.It Pa /etc/passwd 167to map user names to user ID's 168.El 169.Sh EXAMPLES 170.Bd -literal -offset indent 171renice +1 987 -u daemon root -p 32 172.Ed 173.Pp 174changes the priority of process ID's 987 and 32, and 175all processes owned by users daemon and root. 176.Sh SEE ALSO 177.Xr nice 1 , 178.Xr prenice 1 , 179.Xr getpriority 2 , 180.Xr setpriority 2 181.Sh HISTORY 182The 183.Nm 184command appeared in 185.Bx 4.0 . 186.Sh BUGS 187Non-super-users cannot increase scheduling priorities of their own processes, 188even if they were the ones that decreased the priorities in the first place. 189