Linux nice Command Cheat Sheet: CPU Priority Control for SOC Analysts and Admins
Last verified: October 19, 2026, against GNU coreutils behavior and the Linux man pages.
Picture this scenario: it's 3 a.m., and your Linux server monitoring dashboard lights up. The SIEM agent is lagging, log forwarding is delayed, and an analyst can't SSH in without a long pause. Nothing is "down," but something is starving the machine of CPU. It might be a runaway backup job, or it might be an unauthorized process quietly burning cycles.
Either way, the first questions are the same: what is running, and how is it prioritized? That is where nice comes in. In this guide, I'll walk through every command in the cheat sheet, explain what the output means, and show how SOC teams can use nice values for both performance tuning and process auditing in enterprise Linux environments.
Table of Contents
- What nice Actually Does
- Understanding Nice Values and Ranges
- Running Commands with nice
- Inspecting Nice Values with ps
- Background Jobs and PID Capture
- Real-World Jobs: Builds and Compression
- SOC Detection: Auditing Process Priority
- Limitations and Related Tools
- Expert Tips
- FAQ
- Conclusion
What nice Actually Does
According to the GNU coreutils documentation, nice runs a command with a modified "niceness," which is a hint to the Linux scheduler about how willingly a process should give up CPU time. A higher niceness means the process is "nicer" to others and gets a smaller share when CPUs are busy.
One point is easy to miss: nice only matters under contention. If the CPU is idle, a nice 19 process still runs at full speed. The value only changes who wins when several processes compete.
Understanding Nice Values and Ranges
| Nice Value | Meaning | Privilege Needed |
| -20 | Highest scheduling favor | Root or CAP_SYS_NICE |
| 0 | Default for most user processes | None |
| +10 | Default adjustment applied by nice (GNU) | None |
| +19 | Lowest priority | None |
The -n value is an adjustment added to the current niceness, not an absolute setting. Values above 19 are clamped to 19, and values below -20 are clamped to -20.
Running Commands with nice
Default adjustment (+10). With no -n option, GNU nice adds 10:
nice command
Explicit adjustments. These are commands #2, #4, #5, #6, #14, and #15 from the cheat sheet:
nice -n 10 command
nice -n 0 command
nice -n 19 command
nice -n 5 command
nice -n 10 -- command
nice -n 12 -- command
The double dash (--) marks the end of nice's own options. It is good scripting hygiene, especially when the command's arguments start with a hyphen.
Negative adjustments (higher priority). Normal users can't raise their own priority, so this requires elevated privileges:
sudo nice -n -5 command
sudo nice -n -10 command
sudo nice -n -5 -- command
Caution: Raising a process's priority above critical system services can make a server unresponsive. Avoid very negative values unless you have tested the impact.
Passing arguments:
nice -n 10 -- python3 script.py --verbose
Everything after the command name belongs to the command, not to nice.
Inspecting Nice Values with ps
Knowing how to read nice values matters as much as setting them. These commands rely on the ni (nice) and pri (scheduler priority) output columns.
Check your current shell:
ps -o pid,ni,comm -p $$
Expected output is a PID, a nice value (usually 0), and the shell name, such as bash.
List every process with its nice value:
ps -eo pid,ni,comm
ps -eo pid,ni,pri,comm
Sort by nice value:
ps -eo pid,ni,comm --sort=ni
ps -eo pid,ni,comm --sort=-ni
The first form shows the most favored processes (lowest values) at the top. The second shows the "nicest" at the top.
Inspect one process:
ps -o pid,ni,comm -p 1234
ps -o ni= -p 1234
ps -o pid,ppid,user,ni,pri,stat,comm,args -p 1234
The trailing = in ni= suppresses the header, which is handy in scripts. The detailed form adds the parent PID, owner, state, and full command line, which is useful for investigation.
Correlate priority with CPU load:
ps -eo pid,ni,%cpu,comm --sort=-%cpu
A process consuming heavy CPU at nice 19 is a different story from one consuming heavy CPU at nice -10. The second deserves a closer look.
Background Jobs and PID Capture
Long-running maintenance tasks usually go in the background:
nice -n 10 command &
To capture and verify the PID in a script:
nice -n 10 command &
pid=$!
echo "$pid"
ps -o pid,ni,comm -p "$pid"
A simple test you can run safely:
nice -n 15 sleep 300 &
To prove the adjustment is applied, compare your shell with a niced child:
ps -o pid,ni,comm -p $$
nice -n 10 sh -c 'ps -o pid,ni,comm -p $$'
The first line shows your shell's value (typically 0), and the second shows the child at 10 (or higher if your shell was already niced).
Real-World Jobs: Builds and Compression
On shared build servers or production hosts, heavy jobs can crowd out monitoring agents. Lowering their priority is a simple, low-risk mitigation:
nice -n 10 make -j2
nice -n 10 tar -czf archive.tar.gz /path/to/data
Compilation and compression are CPU-bound, so they benefit most. Note that tar writes archive.tar.gz in the current directory, so make sure you aren't overwriting an existing file.
SOC Detection: Auditing Process Priority
This is the part most tutorials skip. Nice values are a useful, if imperfect, triage signal for process monitoring on Linux endpoints. They are not proof of anything on their own.
1. Unusual high-priority processes. Most legitimate processes sit at 0 or above. A process with a negative nice value that you can't tie to a known service or admin action deserves a look. List them with:
ps -eo pid,user,ni,%cpu,comm | awk '$3 < 0'
Expect some legitimate entries, since certain system and audio/real-time services are tuned this way on purpose. Build a baseline of what is normal for your hosts.
2. Heavy CPU at very low priority. Some unauthorized resource-abuse activity, such as cryptomining, is commonly described as trying to stay unobtrusive. One approach is to run at low priority so users notice less slowdown. Treat this as a hunting hypothesis rather than a rule: plenty of legitimate batch jobs are niced too. Start with:
ps -eo pid,user,ni,%cpu,comm --sort=-%cpu | head -15
Then pivot on the owner, the parent process, and the full command line (command #13 above) to decide whether the activity is expected.
3. Privilege context. Changing to a negative nice value needs root or the CAP_SYS_NICE capability. If you find a negative-nice process, ask who launched it and with what privileges. Pair this with your authentication and sudo logs, and with your EDR telemetry where available.
4. Document the baseline. Teams evaluating endpoint detection and response tools or Linux compliance controls often skip basic host-level triage. Capturing a periodic ps -eo pid,user,ni,comm snapshot is cheap and gives incident responders a before-and-after comparison. It supplements, rather than replaces, proper monitoring.
Limitations and Related Tools
- Autogroups. On many modern Linux systems, the kernel's autogroup feature groups processes by session. In that case, nice values mainly affect scheduling within the same group, so the effect can be smaller than you expect. This behavior is described in the kernel's scheduler documentation.
- nice sets priority at launch. To change a process that is already running, use
renice. - CPU only. nice does not control disk I/O. Use
ionicefor that. - Hard limits need other tools. For firm resource ceilings, look at cgroups or systemd resource-control settings rather than nice.
- PRI is not NI. The
pricolumn frompsis a derived scheduler value, and its scale differs between tools. Use thenicolumn when you want the nice value.
Expert Tips
- Nice your own maintenance scripts (backups, log compression, scans) so they never starve security agents.
- Prefer modest values like 10 over 19 in mixed workloads; very low priority jobs can take a long time to finish under load.
- Always use
--in scripts before the command to avoid argument parsing surprises. - Check
man niceandnice --versionon each distro, since BSD and busybox variants can behave differently from GNU. - Treat priority anomalies as a lead to investigate, never as a verdict.
Help and Version Commands
man nice
nice --help
nice --version
These display the manual, option summary, and installed version. Use them to confirm behavior on your specific distribution.
Related Cybersecurity Topics You Should Explore
- iOS 27.0.1 Untethered Jailbreak Explained: Risk and Fixes
- Nextcloud Servers Backdoored: Collabora Flaw CVE-2026-110447
- Linux killall Command: 31 Examples & Safe Usage Cheat Sheet
- Linux pkill Command Cheat Sheet: 40 Safe Examples + pgrep Tips
- Linux Kill Command Cheat Sheet: 37 Examples for SOC Teams
- Linux htop Command Cheat Sheet: Spot Hidden Threats in Seconds
- Linux top Command Cheat Sheet: Find Suspicious Processes Fast
- Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
- Linux ps Command Cheat Sheet: 41 Examples SOC Analysts Use
FAQ
What is the default nice value?
Most user processes start at 0. When you run nice command without options, GNU nice adds 10 to the current value.
Can I use nice without sudo?
Yes, for positive adjustments. Only negative values (higher priority) typically require root or the appropriate capability.
What is the maximum nice value?
19, the lowest priority. The most favorable value is -20.
Does nice make a command faster?
Only under CPU contention, and only relative to other processes. On an idle system, it changes nothing noticeable.
How do I change the priority of a running process?
Use renice, which targets an existing PID instead of launching a new command.
Is a low nice value (high priority) suspicious?
Not by itself. Some legitimate services use it. It becomes interesting when the process is unexpected, unsigned by your baseline, or launched by an unusual user.
Conclusion
The nice command looks like a small utility, but it earns its place in both an admin's and a SOC analyst's toolkit. Used well, it keeps monitoring agents responsive while heavy jobs run. Read well, ps output with nice values gives you quick context during triage. Practice the commands above in a test VM, build a baseline for your own servers, and make priority auditing one small step in your Linux host review routine.
Analysis based on SOC monitoring experience and review of GNU coreutils and Linux man page documentation.
