ExamFinch.com My Study

Study guide

9.2 Adjust Process Scheduling

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

9.2 Adjust Process Scheduling

Key Takeaways Explain This Topic AI

Nice values range from -20 (highest priority) to 19 (lowest); the default is usually 0—higher nice means nicer to others (less CPU favor).

Start a process with a nice value using nice -n N command; change a running process with renice N -p PID (root required for increases in priority / negative nice).

Ordinary users may typically only increase nice (lower priority) on their own processes; lowering nice (boost priority) needs privilege.

Scheduling adjustment is about CPU contention preference, not killing processes or changing systemd unit Enabled state.

Verify with ps -o pid,ni,comm or top (NI column) that the nice value matches the task before moving on.

Last updated: August 2026

9.2 Adjust Process Scheduling

Quick Answer: CPU scheduling preference uses nice values from -20 (favor this process) to 19 (run only when others do not need CPU). Start with nice -n N command . Change live processes with renice N -p PID . Confirm the NI column via ps or top . Root can apply aggressive (negative) nice values; unprivileged users are limited.

Where this fits among “operate running systems”

After you can find and kill hot processes (Section 9.1), the next official skill is to adjust process scheduling . On RHEL this means the classic UNIX nice mechanism that biases the kernel's default fair-share CPU scheduler. On RHEL 10 (kernel 6.12) that scheduler is EEVDF (Earliest Eligible Virtual Deadline First), which replaced the older CFS (Completely Fair Scheduler) in upstream Linux 6.6. The nice / renice interface and the -20..19 range are unchanged by that switch. This is not real-time chrt policy work unless a task explicitly goes there (rare on EX200; master nice/renice first).

Typical tasks:

  • “Start /usr/local/bin/batchjob with nice value 10.”
  • “Set the nice value of process report (or PID …) to 5.”
  • “Ensure the long backup runs at lower priority than interactive work.”

You are changing how hard the process competes for CPU , not stopping it and not configuring tuned profiles (Section 9.3).

Nice value scale

  • Nice value Relative CPU favor
  • 20 Highest priority (least “nice” to others)
  • 0 Default for most processes
  • 19 Lowest priority (most “nice”)

Mnemonic: A higher nice number is nicer to everyone else —your process yields. A negative nice is aggressive and usually root-only .

Related fields you may see:

  • Field Tool Meaning
  • NI top , ps -o ni Nice value
  • PRI top , ps -o pri Kernel priority number (derived; do not confuse with nice)

Do not try to memorize every PRI mapping. EX200 wording almost always says nice value or “priority” in the nice sense—set NI correctly.

  • Starting processes with nice nice command
  • # default nice when using nice without -n is typically +10 on many systems
  • nice -n 10 /usr/local/bin/batchjob
  • nice -n 19 tar czf /backup/home.tgz /home
  • sudo nice -n -5 /usr/local/bin/urgent-job

Notes:

nice applies to the command you start and is inherited by children unless they renice themselves.

Without -n , traditional behavior starts at nice 10 (check man nice on the exam host if unsure)— always pass -n explicitly on the exam so the value is unambiguous.

  • Background example: nice -n 15 longtask.sh > /var/tmp/longtask.log 2>&1 &
  • Changing running processes with renice renice 10 -p 2234
  • renice -n 10 -p 2234 # GNU form also common
  • sudo renice -5 -p 2234 # boost priority (negative nice)
  • renice 5 -u student # all of user's processes (powerful—use carefully)
  • renice 5 -g 1000 # by process group / GID forms per man page
  • Prefer PID form on EX200 unless the task says “all processes for user X.” # Discover then renice
  • pgrep -a report
  • # 55201 report
  • sudo renice 5 -p 55201
  • ps -o pid,user,ni,comm -p 55201
  • Permission rules (critical)
  • Actor Typical allowed change
  • Unprivileged user Raise nice (e.g. 0 → 10) on own processes; cannot renice others’ PIDs
  • Unprivileged user Cannot lower nice (e.g. 10 → 0 or negative) on modern Linux without privilege
  • Root Any nice in range on any process

If renice fails with “Permission denied” or “failed to set priority,” escalate with sudo when the task requires a privileged value or another user’s PID.

  • Verification ps -o pid,user,ni,pri,comm -p PID
  • ps -eo pid,ni,comm --sort=ni | head
  • top -p PID
  • # In top, NI column must match the required value
  • Example success line: PID USER NI COMMAND
  • 55201 root 5 report
  • Also: cat /proc/PID/stat # advanced; nice is among the fields—ps is clearer under time pressure
  • nice vs kill vs services vs tuned
  • Goal Tool
  • Stop a runaway kill / pkill (9.1)
  • Change CPU bias of a live job renice (this section)
  • Start a one-off job softer/harder nice -n
  • System-wide throughput/latency profile tuned-adm (9.3)
  • Start unit at boot systemctl enable (other chapter)

Do not renice systemd (PID 1) as a “fix.” Do not assume renice persists across process restart : a new process gets default nice unless the launcher uses nice again, a service unit sets Nice= , or a wrapper script applies it.

  • systemd Nice= (awareness)
  • Some service units include: Nice=10

in the unit file. Editing units is a services/deploy skill. For “adjust process scheduling” tasks that name a running process , renice is the direct tool. If a task requires a service to always run niced after reboot, you may need unit drop-ins—read the task; do not invent unit edits when a simple renice satisfies “set nice of this process to N now.”

  • Real-time scheduling (brief, do not over-study) chrt -p PID
  • chrt -f 10 command # SCHED_FIFO example—dangerous if misused

Real-time priorities can starve the system. EX200 study points emphasize nice -style adjustment. Only use chrt if a scenario explicitly demands it. Prefer nice / renice for nearly all practice.

  • Exam workflows
  • Workflow 1 — Launch with explicit nice
  • Task: Run /usr/local/bin/crcscan at nice 15. nice -n 15 /usr/local/bin/crcscan &
  • # or foreground if the task expects a long interactive run
  • pgrep -a crcscan
  • ps -o pid,ni,comm -C crcscan
  • Workflow 2 — Fix an already running job
  • Task: Process datamunch must have nice value 10. pgrep -a datamunch

sudo renice 10 -p $(pgrep -n datamunch) # -n newest match; confirm only one PID first!

# Safer:

  • pgrep datamunch
  • sudo renice 10 -p 44120
  • ps -o pid,ni,comm -p 44120

Avoid blind $(pgrep ...) if multiple PIDs match—renice accepts multiple -p or run a loop after listing. for pid in $(pgrep datamunch); do sudo renice 10 -p "$pid"; done

  • ps -o pid,ni,comm -C datamunch
  • Workflow 3 — Lower priority without killing
  • A compile job starves the GUI/SSH interactivity. Soften it: pgrep -a make
  • sudo renice 19 -p 3001

The job keeps running; interactive sessions feel better under load.

  • Workflow 4 — Privileged boost
  • Task: Set nice of PID 2200 to -10. sudo renice -10 -p 2200
  • ps -o pid,ni,comm -p 2200

Without root this fails—use sudo on the exam VM.

Interaction with multi-CPU and load

Nice does not pin a process to a CPU (that is taskset ). Nice does not limit memory ( systemd-run -p MemoryMax= or cgroups). Nice only tilts CPU time sharing when runnable processes compete. On an idle system, even nice 19 may run at full speed because nothing else wants the CPU—that is normal.

Common traps

Inverting the scale — thinking 19 is “highest priority.” It is lowest.

Omitting -n and assuming the default is 0 when using the nice wrapper (default is often +10).

Renicing once then restarting the app—new PID loses the setting.

Using kill -STOP by mistake while trying to “slow” a process—STOP freezes it entirely.

Confusing NI with %CPU — high %CPU can still have NI 0; renice changes preference, not an instant %CPU cap.

renice without verifying — always re-check ps -o ni .

Persistence notes

renice affects the current process until it exits or is reniced again.

Reboot clears all user-space PIDs; nothing about a one-time renice survives unless the job is started again with nice or a unit/ cron wrapper sets it.

For exam tasks phrased as “set the nice value of this running process,” immediate renice + verification is enough.

For “always run this batch at nice 10,” combine scheduling tools (cron/systemd timer) with nice in the command line—covered more fully under task scheduling objectives.

Section checkpoint

You should explain the -20..19 nice scale, start jobs with nice -n , change live jobs with renice , know when root is required, verify with ps / top NI, and avoid confusing scheduling bias with kill or tuned. That meets the EX200 “adjust process scheduling” study point.