Change a Running Process's Nice Value with renice

You will finish with a repeatable way to change the scheduling priority of a running process, process group or user's processes, then confirm the resulting nice 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 requires 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 do not need elevated privileges and make sure that 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.

Checkpoint: you know which renice binary is being used, and you have read its local help before copying an example into a script.

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. Save the value before changing it: that gives you a concrete check and tells you 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. A value of 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 the nice value, such as changing 0 to -5, needs suitable privilege. Do not add sudo automatically: first confirm the target and decide whether giving the process more CPU preference is safe.

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

--relative adds the supplied amount to the current nice value. It 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 have 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 can move 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.

Checkpoint: the test process is back at its recorded value, or it has been stopped, and you have not changed any persistent service configuration.

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. It may also require 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 that the requested change did not fully succeed. Check ownership, the exact PID or group ID, the current nice value and the allowed range. Running the same command with sudo only addresses authorisation; it does not correct a wrong target.