Learn › RHCSA (EX200) › Operate Running Systems
nice - a hands-on Linux lab on a real virtual machine.
Control process priority with nice and renice. The niceness scale from -20 (highest priority) to 19 (lowest), the default 0, launching at a chosen niceness with nice -n N command, changing a running process with renice -n N -p PID, reading NI back with ps -o pid,ni,comm, and the root-only rule for going below 0. Serves EX200 operate task 14: start a workload at a given priority or renice a service.
A nightly backup job kicks off and starts compressing a hundred gigabytes. It is not urgent. It can finish whenever. But it grabs the processor with both hands, and suddenly the web server sharing that machine crawls. Requests time out. Users notice. Nothing crashed. One low-value job simply out-muscled an important one for CPU time.
The kernel had a way to prevent this the whole time. You can tell it, in advance or on the fly, this job is polite, let the others go first. That single control is process priority, and it is EX200 operate task 14: start a workload at a chosen priority, or reprioritize one already running. By the end of this lesson you will set a priority at launch, read it back, and change it on a live process.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs shown are from a real RHEL 10 machine (AlmaLinux 10.2). The PID numbers and the exact process list on your own machine will differ, but the niceness values and the priority rules are the same everywhere, and those are the lesson.
Every process on Linux carries a number called its niceness. It is a hint to the kernel's scheduler about how greedy this process is allowed to be for CPU time. The name is literal: a process with high niceness is being polite, stepping aside so others run first.
The scale runs from -20 to 19. The direction surprises everyone the first time, so fix it now: lower niceness means higher priority, and higher niceness means lower priority. A niceness of -20 is the least polite, most aggressive setting, first in line for the CPU. A niceness of 19 is the most polite, dead last. A brand-new command with no special treatment starts at 0, right in the middle.
The word nice has been in Unix since the 1970s, and it means exactly what it says in plain English. To 'be nice' to the other programs on a shared machine is to lower your own claim on the processor. That is why raising the number lowers your priority: a higher niceness is you being more considerate. The command that reads a niceness back to you is ps, the same process lister you have already met, and the column it prints is labelled NI.
There are two commands, one for each moment. nice sets the niceness when you LAUNCH a command. renice changes the niceness of a process that is ALREADY running. Same idea, two verbs, chosen by whether the process exists yet.
Start by proving the default. When you run any ordinary command, no niceness attached, it lands at 0. You can see this directly with nice itself: run nice with no arguments and it simply prints the niceness the shell would hand out right now.
Before you run it, predict the number. A plain shell gives its children the middle of the road, so you expect:
nice
prompt: student@servera:~$ answer: nice output: 0 hint: Just the four letters and Enter, no flags, no command after it: nice
0. That is the niceness every ordinary command inherits from the shell, the exact middle of the -20 to 19 scale. Nothing you launch normally is greedy or polite by default; it starts even with everything else. Every priority change you make from here is measured against this 0.
Now set a priority at launch. The form is nice -n N command, where N is the niceness you want and command is what to run. The -n flag is not optional in practice: nice -n 10 sleep 60 means run sleep 60 at niceness 10, but nice 10 sleep 60 would try to run a program literally named 10. Always -n.
Here is the whole move in one line. Launch a sleep at niceness 10 in the background, then ask ps for its niceness and name:
nice -n 10 sleep 60 & ps -o ni,comm -p $!
prompt: student@servera:~$ answer: nice -n 10 sleep 60 & ps -o ni,comm -p $! output: 10 bash hint: nice -n 10 launches sleep politely; the & backgrounds it, and $! is the PID of that last background job. Read it with ps -o ni,comm -p $!
The NI column reads 10. The -n 10 told nice to launch the process ten steps politer than default, so instead of the 0 you saw a moment ago, its niceness is 10. That is the entire launch-time skill: nice -n N command starts a workload at exactly the priority you name. A backup you run this way steps aside for the web server automatically.
The command name in that output is whatever process $! pointed at when the capture was taken, so the second column may read differently on your machine. The number that matters, the NI value, is 10 because that is what you asked nice for. Set -n 5 and it would read 5.
Reading niceness deserves its own move, because you will do it constantly to confirm a change landed. The tool is ps with a chosen set of columns: ps -o pid,ni,comm prints just three fields, the process ID, the niceness, and the command name. Nothing else clutters the view.
Run it for your own shell so you see a real, current line:
ps -o pid,ni,comm
prompt: student@servera:~$ answer: ps -o pid,ni,comm output: PID NI COMMAND 1891 0 bash hint: ps with -o and a comma-separated column list, no spaces: ps -o pid,ni,comm
Three columns, exactly the three you asked for. PID is the process number, NI is its niceness, and COMMAND is the program. Your shell (bash) sits at NI 0, the default, because you launched it normally. The PID here is 1891, but yours will be a different number, a process ID is assigned fresh each time. NI is the column your eye trains on: it is how you verify that a nice or renice did what you meant.
The last piece is changing priority AFTER a process is already running. That is renice. The form is renice -n N -p PID: -n N is the new niceness, and -p PID names which process to change by its ID. So renice -n 15 -p 1891 would set process 1891 to niceness 15.
This is the exam's on-the-fly case: a service is already up and you need it to be more polite without restarting it. You find its PID with ps, then renice it. There is one hard limit worth stating before you ever try it.
Only root can LOWER a niceness (make a process more aggressive, toward -20). A regular user may only RAISE it (toward 19), being more polite, never less. Try renice -n -5 as a normal user and you get renice: failed to set priority: Permission denied. Prefix with sudo to go below 0. This trips people on the exam: if the task says set a negative niceness, reach for sudo.
renice also targets in bulk: -u NAME reprioritizes every process owned by a user. But the single-process form, renice -n N -p PID, is the one task 14 asks for, so drill that shape until it is muscle memory.
Scaffolding off. No command is printed this time. You have every piece you need.
A task wants you to start a long sleep 120 at the lowest possible priority, the most polite the scale allows, so it never competes with anything important. Think about which command sets priority at LAUNCH, which flag carries the number, and what the highest number on the niceness scale is. You do not need to background it or read it back; just launch it at that niceness.
prompt: student@servera:~$ answer: nice -n 19 sleep 120 output: hint: Launch-time priority is nice, the flag is -n, and the politest, lowest-priority end of the -20 to 19 scale is 19. Build nice -n <that number> sleep 120.
nice -n 19 sleep 120. The nice command set the priority at launch, -n carried the value, and 19 is the top of the scale, the most polite, lowest-priority setting there is. A job started this way yields to everything else on the machine, which is exactly what you want for background work that must never get in the way. That is task 14 in miniature: pick the priority, name it with -n, and launch.
You earned this cheat sheet. Every row is a form you just ran or built:
The one fact to burn in for the exam: the scale is -20 (highest priority) to 19 (lowest), a plain command starts at 0, lower is greedier, higher is politer, and only root may go below 0.
nice and renice also live inside top. Press r while top is running and it prompts for a PID and a new niceness, an interactive renice. Handy for eyeballing a busy machine, but the command-line forms above are what the exam expects you to type.
The practice terminal has shown you the shape of process priority: the -20 to 19 niceness scale, nice for the default and for launching at a chosen niceness with -n, ps -o pid,ni,comm to read a niceness back, and renice -n N -p PID to change one that is already running, with sudo when you need to go below 0. Every one of those you typed yourself.
The operating-systems module mission is where you run these against a real RHEL 10 machine. A full VM boots for you, systemd running, its own live processes to reprioritize. The mission hands you objectives that use exactly what you practiced here: start a workload at a given niceness, or renice a running one, and prove the NI value with ps. One difference from this lesson: the mission shows no commands. You read the objective, recall the nice and the renice, and type it. That recall is what makes it stick on exam day.
Finish the other operating-systems lessons, then go set a real machine's priorities yourself.
Practice nice and renice in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.