Change a Running Process's Nice Value with renice

A background job hogging CPU does not have to be killed: renice can knock its scheduling priority down while it keeps running. This guide changes the nice value of a running process, process group or user's processes, then confirms the resulting value.

The examples use the renice behaviour documented by util-linux 2.39.3. The renice binary first on this machine reports util-linux 2.42.4, so check your own command if its output differs.

Allow about ten minutes. You need a shell and a process you can safely pause or leave running. Ordinary users can change processes they own, but making a process more favoured normally needs root privileges or an appropriate resource limit. This guide changes live process state, so do not experiment on a database, production worker or other service without an explicit rollback plan.

1. Check the installed command

Start with read-only checks. They need no elevated privileges and confirm the shell will run the expected program:

$ command -v renice
/home/linuxbrew/.linuxbrew/bin/renice
$ renice --version
renice from util-linux 2.42.4
$ renice --help

The syntax is renice --priority PRIORITY --pid PID. Process IDs are the default target type, so --pid is optional, but keeping it in a script makes the target explicit. The local manual also supports --relative, process groups with --pgrp, and usernames or UIDs with --user.

2. Choose a harmless process and record its current value

For a safe test, start a short-lived shell command in the background. It does no useful work and can be stopped after the exercise:

$ sleep 300 &
[1] 2551808
$ TARGET_PID=$!
$ ps -o pid,ni,comm -p "$TARGET_PID"
    PID  NI COMMAND
2551808   0 sleep

Your PID will be different. The NI column is the nice value; zero is the normal starting value. Note the value before changing it, so you have a concrete check and know what an undo would need to restore.

Do not substitute a broad process search for the recorded PID. A command such as pgrep sleep can return several unrelated processes, and a mistaken list can alter work that is not yours.

3. Set an absolute nice value

Use --priority when you want the final value to be unambiguous. A higher nice value means lower scheduling priority:

$ renice --priority 5 --pid "$TARGET_PID"
2551808 (process ID) old priority 0, new priority 5
$ ps -o pid,ni,comm -p "$TARGET_PID"
    PID  NI COMMAND
2551808   5 sleep

The displayed PID and old value are variable. The useful result is that the command reports the old and new priorities, and ps shows 5 in NI. The value range is -20 to 19: negative values favour the process, positive values make it less favoured, and 19 is deliberately very low priority.

For an ordinary user, raising the nice value, such as changing 0 to 5, is usually allowed for a process that user owns. Lowering it, such as changing 0 to -5, needs suitable privilege. Do not add sudo automatically: confirm the target first, and decide whether giving the process more CPU preference is actually safe.

4. Use a relative adjustment when that is the real intent

--relative adds the supplied amount to the current nice value, which is useful when you want to make a process less favoured without assuming its starting value:

$ renice --relative 2 --pid "$TARGET_PID"
2551808 (process ID) old priority 5, new priority 7
$ ps -o pid,ni,comm -p "$TARGET_PID"
    PID  NI COMMAND
2551808   7 sleep

Positive and negative adjustments follow the same direction as absolute values: 2 lowers scheduling priority, while -2 attempts to raise it. The final value cannot go outside the supported range. Treat a relative change as stateful: rerunning it moves the process again.

There is a confusing historical corner: the short -n option is absolute by default in this implementation, but becomes relative when POSIXLY_CORRECT is set. Use --priority or --relative in scripts, so an environment variable cannot change the meaning of the command.

5. Restore the original value or stop the test

Restoring the recorded value is the undo operation for this example. Because the original value was 0, set that exact value:

$ renice --priority 0 --pid "$TARGET_PID"
2551808 (process ID) old priority 7, new priority 0
$ ps -o pid,ni,comm -p "$TARGET_PID"
    PID  NI COMMAND
2551808   0 sleep
$ kill "$TARGET_PID"
$ wait "$TARGET_PID" 2>/dev/null || true

If you did not record the old value, do not guess it: inspect the process history, leave the value alone, or ask the process owner. An unprivileged user can generally increase a nice value but cannot necessarily decrease it again. The manual describes such changes as irreversible unless the process has a suitable nice resource limit.

6. Target groups or all processes for a user

Use --pgrp when the intended unit is a process group ID, and --user for a username or UID. These affect more than one process, so inspect the target before changing it:

$ ps -o pid,pgid,user,ni,comm -p PID
$ renice --priority 10 --pgrp PROCESS_GROUP_ID
$ renice --priority 10 --user USERNAME

Replace each uppercase placeholder with a verified value. The second command can change every process owned by that user, including work you did not start, and it may also need elevated privileges. Prefer a PID when one process is all you need, and do not use a username-wide change as a quick performance fix.

A non-zero exit status, or an error naming a process, means the requested change did not fully succeed. Check ownership, the exact PID or group ID, the current nice value and the allowed range. Rerunning the same command with sudo only addresses authorisation; it does not correct a wrong target.