Lower a Command's Scheduling Priority with nice
Use GNU nice to start a program with a less favourable scheduling priority, then check the value from inside the child process. This is useful for batch work that should yield CPU time to interactive services. It does not cap CPU usage, pause a process, or make a command safe to run as root.
The route
Jump straight to the step you need, or tick off Done means at the end.
You need a POSIX-like shell, GNU coreutils nice, and the ps command for the verification examples. Allow about five minutes. The examples only start short-lived shell processes and write no files, so no elevated privileges are needed.
1. Check the current niceness
Run nice without a command. It prints the niceness of the current shell process:
$ /usr/bin/nice
0
GNU nice accepts values from -20 to 19. A lower number is more favourable to the process; a higher number makes it more willing to yield when competing for CPU. The normal starting value is usually 0, but the inherited value is what matters for a particular shell.
Checkpoint: if this prints a number, you have confirmed which niceness your current shell exposes. Use the absolute path shown above when a shell builtin could otherwise hide the GNU implementation.
2. Start one command with a lower priority
Pass an adjustment with -n or --adjustment. The adjustment is added to the inherited niceness. With no option, GNU nice adds 10:
$ /usr/bin/nice -n 7 sh -c 'ps -o ni= -p $$'
7
$ /usr/bin/nice sh -c 'ps -o ni= -p $$'
10
The first command starts a shell at niceness 7. The second uses the default adjustment and starts its child at niceness 10. The leading spaces in ps's output are display padding, not part of the value.
Use a command with its arguments after the adjustment. Quote arguments that belong to the child shell, as in this harmless status example:
$ /usr/bin/nice -n 12 sh -c 'printf "child niceness: "; ps -o ni= -p $$'
child niceness: 12
Checkpoint: the number printed by ps should equal the parent niceness plus the requested adjustment. This verifies the setting in the process that actually runs the work, rather than relying on an assumed default.
3. Choose the adjustment carefully
For ordinary background work, a positive adjustment such as 5, 10, or 12 is the usual boundary. It changes the scheduling preference for this process and descendants that inherit it. It does not guarantee that the process will receive less CPU: if the machine is otherwise idle, the program can still use an available CPU.
Do not treat negative adjustments as a routine performance switch. A negative value asks for more favourable scheduling, and an unprivileged user normally cannot increase its priority. Test the request without hiding the diagnostic:
$ /usr/bin/nice -n -5 true
/usr/bin/nice: cannot set niceness: Permission denied
$ printf 'exit status: %s\n' "$?"
exit status: 125
The exact diagnostic can vary with the system, but GNU nice documents status 125 when nice itself fails. An administrator may be able to use a negative adjustment under the host's policy; do not add sudo merely to make a batch job faster. Elevated privileges change the security boundary and can give the child access it did not otherwise have.
Checkpoint: keep positive adjustments for workload politeness. If a service needs a defined CPU share, use the service manager or a resource controller designed for that job instead of assuming nice is a hard limit.
4. Keep the shell and exit status straight
Some shells provide their own nice builtin, which can take different options. Compare or bypass it with command -V nice and the explicit /usr/bin/nice path:
$ command -V nice
$ /usr/bin/nice --version
nice (GNU coreutils) 9.4
The installed package here is coreutils 9.4. The command's documented exit status is normally the exit status of the child, so a successful launch does not turn a failed workload into success. These two checks show the distinction:
$ /usr/bin/nice sh -c 'exit 23'
$ printf 'child status: %s\n' "$?"
child status: 23
$ /usr/bin/nice definitely-not-a-command >/dev/null 2>&1
$ printf 'missing command status: %s\n' "$?"
missing command status: 127
GNU nice uses 127 when the command cannot be found and 126 when it is found but cannot be invoked. It uses 125 for a failure in nice itself. Preserve and check these statuses in scripts instead of checking only whether the child printed anything.
5. Undo the example
There is no persistent configuration to undo: niceness belongs to a process. When the command exits, its setting disappears. To stop a long-running test, use its normal application shutdown or send a signal to the specific process after checking its PID. Do not kill a production process just because it has a different niceness.
For a command you have not yet run, remove the /usr/bin/nice ... prefix. For a command already running at a lower priority, renice is the separate tool for changing an existing process, with its own permissions and targeting risks.
Done means
- You can read the current niceness with
/usr/bin/nice. - You can start one command with an explicit positive adjustment and verify it with
ps. - You know that the default GNU adjustment is 10, not zero.
- Your script preserves the child's exit status and distinguishes 125, 126, and 127.
- You have not confused a scheduling preference with a CPU limit or added privileges unnecessarily.