LFCS 56 🐧 Process Priority — nice, renice - KandZ

⏱️ Estimated read: 13 min | |

Every process on a Linux system competes for CPU time, and the scheduler decides who gets the processor and for how long. The nice value is the user-space lever for influencing that decision. It is an integer from -20 to 19, where -20 is the highest priority and 19 is the lowest . The name comes from the idea that a process with a high nice value is being “nice” to other processes by yielding more CPU time to them . The default is 0, and most processes run there without any intervention. The LFCS exam expects you to know how to start a process with a different priority and how to change the priority of a process that is already running .

The two commands are nice and renice. nice launches a new command with a specified niceness. renice modifies the niceness of an existing process by its PID, its user, or its process group . The distinction matters because the scheduler reads the nice value at the moment it makes a decision; changing it on a running process takes effect immediately, without a restart. The privilege rule is the other half of the topic: an unprivileged user can increase the nice value (lower the priority) of their own processes, but only root can decrease it (raise the priority) or change another user’s process .

Key point: Nice values range from -20 (highest priority) to 19 (lowest priority), with 0 as the default. nice -n 10 command starts a command with a lower priority; renice 15 -p PID changes a running process to the same. Negative nice values require root or a configured limit, because they give the process a larger share of CPU time.

Why nice and renice exist

The fairness problem. The Linux scheduler is designed to share the CPU fairly among all runnable processes. But “fair” is not always “correct.” A backup job that will run for six hours should not compete on equal terms with the web server that serves user requests. The nice value is the mechanism that lets the administrator express that judgment. A higher nice value tells the scheduler that the process is willing to wait; a lower nice value tells the scheduler that the process has a stronger claim on the CPU .

The dynamic priority problem. The nice value is not the priority itself. It is an input to the scheduler’s calculation. The kernel uses the nice value to compute a dynamic priority, which determines the length of the time slice a process receives when it is scheduled. A process with a nice value of 19 receives a much smaller time slice than a process with a nice value of -20 . The nice value is the upper and lower bound on that dynamic priority, which is why it is described as the “niceness” rather than the priority. The ps command’s PRI column shows the computed priority, while the NI column shows the nice value .

The privilege problem. If any user could set a negative nice value, the priority system would be meaningless. Every process would run at -20, and the scheduler would have no way to distinguish the critical from the trivial. The kernel enforces the rule: an unprivileged process can only increase its nice value, never decrease it. Root, or a user with a raised limit in /etc/security/limits.conf, can set negative values . This is the security boundary that makes the nice value meaningful.

The operational problem. A long-running CPU-intensive task—a kernel compile, a video encode, a database migration—can saturate the CPU and make the interactive session unresponsive. The fix is not to kill the task; it is to renice it. renice 19 -p PID pushes it to the lowest priority, and the interactive processes regain their responsiveness. This is the proactive alternative to kill .

a. The nice command: starting a process with a priority

The nice command starts a new process with a specified niceness. The -n flag sets the adjustment, and the default adjustment is +10 if no flag is given . The adjustment is relative to the current nice value, which is usually 0 for a process started from an interactive shell.

# Start a backup script with a nice value of 10
# The backup runs at a lower priority than the default
# It will not compete with interactive processes
nice -n 10 /usr/local/bin/backup.sh

# Start a compression job with the default nice adjustment
# The default is +10, so the process runs at nice 10
nice tar -czf backup.tar.gz /path/to/data

# Start a critical task with a high priority
# The negative value requires root or a configured limit
# The -n -5 sets the nice value to -5
sudo nice -n -5 /usr/local/bin/critical-task

The nice command without -n is the same as nice -n 10. The default is not zero; it is a +10 adjustment. A process started with nice from a shell that already has a nice value of 10 receives a value of 20, which is capped at 19 . The adjustment is relative, not absolute, which is why the -n flag is the explicit form.

The ps command verifies the result. The -l flag shows the long format, and the NI column shows the nice value.

# Start the process with nice 15 in the background
nice -n 15 yes > /dev/null &

# Find the PID of the yes process
# pidof returns the PID of the named process
PID=$(pidof yes)

# Check the nice value with ps
# The -o flag selects the PID, NI (nice), and COMMAND columns
ps -o pid,ni,comm -p $PID
# Output: PID NI COMMAND
#         1234 15 yes

The ps -o pid,ni,comm -p $PID form is the precise check. The NI column is the nice value, and it should show 15. The ps -l form shows the same information with more columns, and the top or htop tools show it in the NI column of the process list .

b. The renice command: changing a running process

renice changes the nice value of a process that is already running. The syntax takes the new value and the target. The target can be a PID (-p), a user (-u), or a process group (-g).

# Change the nice value of a single process
# The PID is the target
# The new value is 15
renice 15 -p 1234

# Change the nice value of all processes owned by a user
# The -u flag targets the user
# This requires root for another user's processes
sudo renice 10 -u backupuser

# Change the nice value of a process group
# The -g flag targets the process group
renice 5 -g 5678

The -n flag is optional with renice. The first positional argument is the new nice value, and the target flag follows. The --relative option changes the value by an increment rather than setting it to an absolute value .

# Increase the nice value by 5
# If the current value is 10, the new value is 15
renice --relative 5 -p 1234

# Decrease the nice value by 5
# This requires root because it raises the priority
sudo renice --relative -5 -p 1234

The privilege rule is the same as with nice. An unprivileged user can increase the nice value of their own processes, which lowers the priority. They cannot decrease it, because that would raise the priority. Root can do both, and root can change the nice value of any process . The renice command does not require the process to be stopped; the change takes effect at the next scheduling decision.

The top and htop tools are the interactive way to renice. In top, pressing r prompts for a PID and a new nice value. In htop, pressing F7 decreases the nice value (raises priority) and F8 increases it (lowers priority) for the selected process . The ps command is the verification tool after the change.

c. The operational patterns and the limits

The most common operational pattern is to start a long-running background task with a high nice value so that it does not interfere with interactive work, and then to renice it if the system becomes unresponsive.

# Start the compile with a low priority
# The -n 19 is the lowest possible priority
nice -n 19 make -j4 &

# The compile runs in the background
# If the system is still responsive, the nice value is working
# If the system becomes sluggish, renice the process
# Find the PID of the make process
PID=$(pidof make)

# Push it to the lowest priority
renice 19 -p $PID

# Check the result
ps -o pid,ni,comm -p $PID

The /etc/security/limits.conf file is the mechanism that allows a specific user to set negative nice values without full root access. The nice limit is a resource limit, and a line like appuser hard nice -10 allows the appuser to set a nice value as low as -10 . This is the controlled way to give a service the ability to raise its own priority without giving it root.

# The limits.conf entry
# The user is appuser
# The type is hard, which is the maximum the user can set
# The item is nice
# The value is -10, which is the lowest nice value the user can set
appuser hard nice -10

The ionice command is the companion for I/O priority. The nice value controls CPU scheduling, but it does not control disk I/O. A backup job with a high nice value can still saturate the disk and make the system unresponsive. The ionice -c 3 class sets the I/O priority to “idle,” which means the process only gets disk time when no other process needs it .

# Combine nice and ionice for a background backup
# The nice value lowers the CPU priority
# The ionice class 3 lowers the I/O priority
nice -n 10 ionice -c 3 /usr/local/bin/backup.sh

The systemd service unit has a Nice= directive for the same purpose. A service that should run at a lower priority can set Nice=10 in its unit file, and systemd applies the value when it starts the process .

Complete Example Session

The following session starts a CPU-intensive process, verifies its nice value, re-nices it, and confirms the change.

# ============================================
# PART 1: START THE PROCESS WITH nice
# ============================================
# Start the yes command with a nice value of 10
# The yes command produces infinite output, so it is a CPU load
# The output is redirected to /dev/null to avoid filling the terminal
# The & puts it in the background
nice -n 10 yes > /dev/null &

# ============================================
# PART 2: FIND THE PID
# ============================================
# The pidof command returns the PID of the yes process
PID=$(pidof yes)
# Print the PID
echo "PID: $PID"

# ============================================
# PART 3: VERIFY THE NICE VALUE
# ============================================
# The ps command shows the nice value
# The -o flag selects the PID, NI, and COMMAND columns
ps -o pid,ni,comm -p $PID
# Expected output: 12345  10 yes

# ============================================
# PART 4: RENICE THE PROCESS
# ============================================
# Change the nice value to 19 (the lowest priority)
# This requires no special privilege because it lowers the priority
renice 19 -p $PID
# Output: 12345 (process ID) old priority 10, new priority 19

# ============================================
# PART 5: VERIFY THE CHANGE
# ============================================
# Check the new nice value
ps -o pid,ni,comm -p $PID
# Expected output: 12345  19 yes

# ============================================
# PART 6: CLEAN UP
# ============================================
# Kill the process
kill $PID

The six parts cover starting the process with a nice value, finding the PID, verifying the value, changing it, verifying the change, and cleaning up. What the session demonstrates is that nice sets the value at launch, renice changes it at runtime, and ps -o ni is the verification.

Quick Reference

Nice Value Range

Value	Priority	Privilege
`-20`	Highest	Root or limit
`0`	Default	Any user
`19`	Lowest	Any user

Commands

Command	Purpose
`nice -n N command`	Start with nice value N
`nice command`	Start with default +10
`renice N -p PID`	Set nice value of PID
`renice N -u user`	Set nice value of user’s processes
`renice --relative N -p PID`	Adjust by N

Verification

Command	Shows
`ps -o pid,ni,comm -p PID`	Nice value of a process
`ps -l`	Long format with NI
`top`	NI column
`htop`	NI column

Limits

File	Purpose
`/etc/security/limits.conf`	Per-user nice limit

Best Practices

✅ Do This:

# Start a background task with low priority
nice -n 10 backup.sh

# Renice a running process to the lowest priority
renice 19 -p 1234

# Combine nice and ionice for I/O-heavy tasks
nice -n 10 ionice -c 3 backup.sh

# Verify the value
ps -o pid,ni,comm -p 1234

❌ Don’t Do This:

# Try to raise priority without root
renice -5 -p 1234 # permission denied

# Assume nice controls I/O
nice -n 19 cp hugefile # still saturates the disk

# Forget the -n flag for an absolute value
nice 10 command # invalid syntax

Common Pitfalls

Pitfall	Why It Happens	Fix
`nice 10 command` fails	Missing `-n`	`nice -n 10 command`
`renice` permission denied	Negative value without root	Use `sudo`
Nice value ignored	Process is CPU-bound but I/O-bound	Use `ionice`
Value capped at 19	Adjustment from a non-zero base	Check the base value
`ps` does not show NI	Used `ps aux` without NI column	`ps -o ni`

Real-World Examples

1. Start with nice

nice -n 10 make -j4

2. Renice by PID

renice 15 -p 1234

3. Renice by user

sudo renice 10 -u backupuser

4. Relative renice

renice --relative 5 -p 1234

5. Verify nice value

ps -o pid,ni,comm -p 1234

6. Highest priority

sudo nice -n -20 critical-task

7. Lowest priority

nice -n 19 backup.sh

8. Limits config

appuser hard nice -10

9. Systemd Nice

[Service]
Nice=10

10. Combine with ionice

nice -n 10 ionice -c 3 backup.sh

Visual

Nice Value Range

┌──────────────────────────────────────────────┐
│  -20 ──────────── 0 ──────────── 19          │
│  Highest        Default        Lowest        │
│  Priority                      Priority      │
│                                              │
│  Root only     Any user        Any user      │
└──────────────────────────────────────────────┘

nice vs renice

┌──────────────────────────────────────────────┐
│  nice                                        │
│  → starts a new process                      │
│  → nice -n 10 command                        │
│                                              │
│  renice                                      │
│  → changes an existing process               │
│  → renice 15 -p PID                          │
└──────────────────────────────────────────────┘

Privilege Rule

┌──────────────────────────────────────────────┐
│  Unprivileged user                           │
│  → can increase nice value (lower priority)  │
│  → cannot decrease nice value                │
│                                              │
│  Root                                        │
│  → can set any value on any process          │
│                                              │
│  limits.conf                                 │
│  → grants a user a specific negative limit   │
└──────────────────────────────────────────────┘

Summary

Item	Value
Range	`-20` to `19`
Default	`0`
Higher value	Lower priority
Lower value	Higher priority
Start with priority	`nice -n N command`
Change running	`renice N -p PID`
Negative value	Root or limit
Verification	`ps -o pid,ni,comm`
I/O companion	`ionice`
Systemd	`Nice=`

Key takeaways:

The nice value is not the priority; it is the input to the priority calculation. The scheduler uses it to compute the dynamic priority and the time slice. The ps PRI column shows the computed priority, and the NI column shows the nice value .
nice starts a process; renice changes a running one. The nice command takes -n and the adjustment. The renice command takes the new value and a target flag (-p, -u, -g) .
The privilege rule is the security boundary. An unprivileged user can lower the priority (increase the nice value) of their own processes. Raising the priority (decreasing the value) requires root or a limit in /etc/security/limits.conf .
The nice value only controls CPU scheduling. A process with a high nice value can still saturate the disk. The ionice command is the companion for I/O priority .
The default adjustment for nice is +10, not 0. A bare nice command runs at nice 10. The -n flag is the explicit form .
renice supports relative adjustment. The --relative option changes the value by an increment rather than setting it to an absolute value .

Remember: The nice value is the administrator’s way of telling the scheduler which processes can wait. A high nice value means the process yields CPU time to others; a low nice value means it has a stronger claim. The nice command sets the value at launch, and renice changes it at runtime. The privilege rule is what makes the value meaningful: only root can claim a stronger claim than the default, and the limits.conf file is the controlled exception. The ps NI column is the verification, and ionice is the I/O companion. The LFCS exam expects you to know the range, the commands, the privilege rule, and the distinction between CPU priority and I/O priority.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!