RED HAT ENTERPRISE LINUX

Process Management

Investigate, Control, and Terminate Processes

College-Level Course Module | RHEL System Administration

Welcome to this essential module on process management in Linux. Every program running on your system - whether it is a web server, a database, a user application, or a system service - runs as one or more processes. Understanding how to investigate, control, and terminate processes is fundamental for system administration. You will encounter situations where processes consume too much CPU, use excessive memory, become unresponsive, or need to be stopped for maintenance. You need to identify which processes are causing problems, understand their resource usage, and take appropriate action. In this module, you will learn what processes are and how Linux manages them, how to view and investigate running processes, how to control processes in the foreground and background, how to send signals to control or terminate processes, and how to adjust process priorities. These skills are essential for maintaining system health and troubleshooting performance issues.

Learning Objectives

Understand processes

Process concepts, states, and the process hierarchy

Investigate processes

Use ps, top, and other tools to view process information

Control job execution

Manage foreground and background processes

Send signals to processes

Use kill and related commands to control processes

Adjust process priority

Use nice and renice to manage CPU scheduling

We have five main learning objectives. First, you will understand what processes are - the fundamental concepts of how Linux executes programs, process states, and the parent-child relationship between processes. Second, you will investigate processes using tools like ps for snapshots and top for real-time monitoring. You will learn to identify resource-hungry processes and understand what they are doing. Third, you will control job execution - managing foreground and background processes, suspending and resuming work, and keeping processes running after logout. Fourth, you will send signals to processes using kill and related commands. Signals are how you communicate with processes - telling them to terminate, reload configuration, or take other actions. Fifth, you will adjust process priority using nice and renice to control how the CPU scheduler allocates time to competing processes.

What is a Process?

A process is a running instance of a program. When you execute a command, the kernel creates a process, assigns it resources, and schedules it for execution.

Process Attributes:

PID - Unique Process ID
PPID - Parent Process ID
UID/GID - User/Group ownership
Priority - Scheduling priority
State - Current execution state
Memory - Allocated memory space

Program vs Process:

Program - Executable file on disk
Process - Running program in memory
One program can spawn many processes
Each process has isolated memory
Processes share CPU time

# Every process has a unique PID
[user@host ~]$ echo $$
1234            # Current shell's PID

A process is a running instance of a program. The distinction is important - a program is a file containing executable code stored on disk. When you run that program, the kernel creates a process - an active entity in memory with its own resources. Every process has attributes the kernel uses to manage it. The PID (Process ID) uniquely identifies each process. No two processes have the same PID at the same time. The PPID (Parent Process ID) identifies which process created this one. The UID and GID determine what the process can access based on user and group permissions. Priority affects CPU scheduling - which processes run when. State indicates what the process is currently doing. Memory allocation gives the process its own address space, isolated from other processes. One program can run as multiple processes. For example, if you open three terminal windows, you have three bash processes, all from the same /bin/bash program. The special variable $$ contains the current shell's PID.

Process States

Processes move between states as they execute. Understanding states helps diagnose process behavior.

State	Code	Description
Running	R	Currently executing on CPU or waiting in run queue
Sleeping (Interruptible)	S	Waiting for event (I/O, signal) - can be interrupted
Sleeping (Uninterruptible)	D	Waiting for I/O - cannot be interrupted (disk wait)
Stopped	T	Suspended by signal (Ctrl+Z) or debugger
Zombie	Z	Terminated but parent hasn't read exit status

Created

→

Ready

↔

Running

→

Terminated

Processes transition between states as they execute. Understanding these states helps you diagnose what processes are doing. Running (R) means the process is either executing on a CPU core or is ready to run and waiting for CPU time. Most processes are not actually running at any given moment - they are waiting their turn. Sleeping Interruptible (S) is the most common state. The process is waiting for something - user input, network data, a timer. It can be woken by signals. Most processes you see will be in this state. Sleeping Uninterruptible (D) means waiting for I/O that cannot be interrupted, typically disk operations. A process stuck in D state often indicates storage problems. You cannot kill a D-state process until the I/O completes. Stopped (T) means the process was suspended, usually by Ctrl+Z or a debugger. It is not running and will not run until resumed. Zombie (Z) is an unusual state. The process has terminated, but its parent has not yet read its exit status. The process entry remains so the parent can retrieve this information. Many zombies indicate a buggy parent process.

Process Hierarchy

Processes form a parent-child hierarchy. Every process (except PID 1) has a parent. When processes create new processes, they become children.

# View process tree
[user@host ~]$ pstree
systemd─┬─NetworkManager───3*[{NetworkManager}]
        ├─agetty
        ├─auditd───{auditd}
        ├─crond
        ├─sshd───sshd───sshd───bash───pstree
        └─systemd-journal

# Show PIDs in tree
[user@host ~]$ pstree -p
systemd(1)─┬─sshd(1234)───sshd(5678)───sshd(5680)───bash(5681)───pstree(5700)

# Show tree for specific process
[user@host ~]$ pstree -p 1234

PID 1 (systemd): The first process started at boot. It is the ancestor of all other processes and adopts orphaned processes.

Linux processes form a hierarchy - a tree structure with PID 1 at the root. When a process starts another process, the new one is a child of the original. The parent-child relationship is tracked through PPID. PID 1, which is systemd on RHEL, is special. It starts at boot and is the ultimate ancestor of all processes. When a process's parent terminates before the child, the orphaned child is adopted by PID 1. pstree visualizes this hierarchy. You can see how sshd spawns child processes for each SSH connection, which spawn shells, which spawn commands. The -p option shows PIDs alongside process names. This is useful for understanding which PID corresponds to what. You can also focus on a subtree by specifying a PID. This hierarchy matters because signals and job control work within it, and because parent processes are responsible for cleaning up after their children. If a parent does not properly wait for its children, you get zombie processes.

Viewing Processes: ps

ps (process status) displays a snapshot of current processes. Different options show different information.

# Basic ps - shows processes in current terminal
[user@host ~]$ ps
  PID TTY          TIME CMD
 5681 pts/0    00:00:00 bash
 5700 pts/0    00:00:00 ps

# Show all processes (BSD style - most common)
[user@host ~]$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
root         1  0.0  0.3 171820 13256 ?     Ss   09:00   0:02 /usr/lib/systemd/systemd
root         2  0.0  0.0      0     0 ?     S    09:00   0:00 [kthreadd]
apache    1234  0.2  1.5 550000 62000 ?     S    09:15   0:45 /usr/sbin/httpd
student   5681  0.0  0.1  27000  4500 pts/0 Ss   10:30   0:00 -bash

# Show all processes (Unix style)
[user@host ~]$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 09:00 ?        00:00:02 /usr/lib/systemd/systemd
student   5681  5680  0 10:30 pts/0    00:00:00 -bash

ps is your primary tool for viewing processes. Plain ps shows only processes in your current terminal - usually just your shell and ps itself. This is rarely what you want. ps aux is the most common form. It shows all processes with detailed information. The columns show: USER (owner), PID, CPU percentage, memory percentage, virtual memory size, resident set size (actual RAM), terminal, state, start time, CPU time consumed, and command. ps -ef is the Unix-style alternative, showing UID, PID, PPID (parent), CPU usage, start time, terminal, accumulated time, and command. Both aux and -ef show all processes on the system. The difference is mainly formatting preference. Note that ps options have quirks - aux without a dash is BSD style, -ef with dash is Unix style. Mixing them can cause unexpected results. Most administrators use aux for the additional resource columns.

Understanding ps Output

Column	Description	Example
USER	Process owner	root, apache, student
PID	Process ID	1, 1234, 5681
%CPU	CPU usage percentage	0.0, 25.5, 99.9
%MEM	Memory usage percentage	0.1, 5.2, 15.0
VSZ	Virtual memory size (KB)	Total addressable memory
RSS	Resident Set Size (KB)	Actual physical RAM used
TTY	Controlling terminal	pts/0, tty1, ? (none)
STAT	Process state	S, R, D, T, Z (+ modifiers)
START	When process started	09:00, Jan15
TIME	Cumulative CPU time	0:00, 5:32
COMMAND	Command that started process	/usr/sbin/httpd

# STAT column modifiers:
s - session leader      l - multi-threaded
+ - foreground process  < - high priority
N - low priority        L - pages locked in memory

Understanding ps output columns helps you quickly assess process health. USER shows who owns the process - this determines what the process can access. PID is the unique identifier you use to reference this process. %CPU shows current CPU utilization. Values over 100% are possible on multi-core systems. %MEM shows the percentage of physical RAM used. High values indicate memory-hungry processes. VSZ is virtual memory - the total address space. This includes shared libraries and memory that might be swapped out. It is often misleadingly large. RSS (Resident Set Size) is more useful - it is actual physical RAM currently used by the process. TTY shows the controlling terminal. A question mark means no terminal - typically daemons and services. STAT shows state plus modifiers. Ss means sleeping session leader. R+ means running foreground process. TIME is cumulative CPU time - how much CPU the process has consumed since starting. COMMAND shows what was executed. Arguments are included, which helps identify specific instances.

Filtering ps Output

# Find processes by name using grep
[user@host ~]$ ps aux | grep httpd
root      1234  0.0  0.5 275000 20000 ?  Ss  09:15  0:00 /usr/sbin/httpd
apache    1235  0.0  0.3 275500 12000 ?  S   09:15  0:01 /usr/sbin/httpd
apache    1236  0.0  0.3 275500 12000 ?  S   09:15  0:01 /usr/sbin/httpd
student   5720  0.0  0.0  12000  1000 pts/0 S+ 10:45 0:00 grep httpd

# Exclude grep from results
[user@host ~]$ ps aux | grep [h]ttpd
[user@host ~]$ ps aux | grep httpd | grep -v grep

# Find processes by user
[user@host ~]$ ps -u apache
[user@host ~]$ ps aux | grep ^apache

# Find process by PID
[user@host ~]$ ps -p 1234

# Custom output format
[user@host ~]$ ps -eo pid,user,%cpu,%mem,cmd --sort=-%cpu | head
  PID USER     %CPU %MEM CMD
 3456 mysql    45.2 12.5 /usr/libexec/mysqld
 1234 apache    8.3  2.1 /usr/sbin/httpd

Raw ps aux output can be overwhelming. Filtering helps find what you need. Piping through grep finds processes by name. One annoyance - grep itself shows up in results because its command line contains the search term. The trick grep [h]ttpd works because [h] matches h but the literal command line contains [h], not h, so grep does not match itself. Filtering by user with ps -u shows only that user's processes. Useful for checking what a service account is running. ps -p queries a specific PID. Useful when you know the PID and want details. Custom formatting with -eo (every process, output format) lets you choose exactly which columns to display. Combined with --sort, you can rank by resource usage. The example sorts by CPU descending (the minus sign means descending) and shows the top consumers. This is invaluable for finding resource hogs.

Real-time Monitoring: top

top provides a dynamic, real-time view of processes. It updates continuously and allows interactive sorting and filtering.

[user@host ~]$ top
top - 10:45:23 up 1 day,  2:30,  2 users,  load average: 0.15, 0.10, 0.05
Tasks: 156 total,   1 running, 155 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.3 us,  1.0 sy,  0.0 ni, 96.5 id,  0.1 wa,  0.0 hi,  0.1 si
MiB Mem :   3936.0 total,   1524.0 free,   1200.0 used,   1212.0 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   2500.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3456 mysql     20   0 1256000 512000  15000 S  12.3  12.7   5:23.45 mysqld
 1234 apache    20   0  275000  62000  12000 S   2.5   1.5   0:45.12 httpd
    1 root      20   0  171820  13256   8500 S   0.0   0.3   0:02.35 systemd

Key metrics in header: Load average (1, 5, 15 min), CPU breakdown (user, system, idle, wait), Memory usage

top is the go-to tool for real-time process monitoring. Unlike ps, which shows a snapshot, top updates continuously (every 3 seconds by default). The header provides system-wide statistics. Load average shows CPU demand over 1, 5, and 15 minutes. Values should be less than your CPU core count. The Tasks line counts processes by state. CPU percentages break down into user (us), system (sy), nice (ni), idle (id), I/O wait (wa), and interrupts (hi, si). High wa suggests disk bottleneck. Memory shows total, free, used, and buffer/cache. Available memory is what can be given to processes if needed. The process list shows individual processes, sorted by CPU by default. PR is priority, NI is nice value, VIRT is virtual memory, RES is resident memory, SHR is shared memory, S is state. top is interactive - you can change sorting, filter by user, kill processes, and more.

Interactive top Commands

Key	Action	Key	Action
h or ?	Help screen	q	Quit top
M	Sort by memory	P	Sort by CPU (default)
N	Sort by PID	T	Sort by time
u	Filter by user	c	Toggle full command
k	Kill a process	r	Renice a process
1	Toggle per-CPU stats	m	Toggle memory display
Space	Refresh immediately	d	Change refresh delay

# Start top sorted by memory
[user@host ~]$ top -o %MEM

# Show only specific user's processes
[user@host ~]$ top -u apache

# Batch mode (for scripting, non-interactive)
[user@host ~]$ top -bn1 | head -20

# Set refresh interval to 1 second
[user@host ~]$ top -d 1

top is highly interactive. Learn these keys to use it efficiently. M sorts by memory usage - essential for finding memory hogs. P returns to CPU sorting. These are uppercase letters. u prompts for a username and filters to show only that user's processes. Press u and enter to clear the filter. k prompts for a PID and signal to send - you can kill processes without leaving top. r prompts for a PID and new nice value to reprioritize processes. The number 1 toggles between aggregate and per-CPU statistics. On multi-core systems, this shows individual core utilization. c toggles between showing just the command name versus the full command line with arguments. d changes the refresh delay - useful if 3 seconds is too slow or too fast. Command-line options let you customize top from the start. -o sets initial sort column, -u filters by user, -b is batch mode for capturing output in scripts, -d sets refresh interval.

Other Monitoring Tools

# htop - enhanced interactive process viewer (if installed)
[user@host ~]$ htop
# Better visual interface, mouse support, easier to use

# pidof - find PID by process name
[user@host ~]$ pidof httpd
1236 1235 1234

# pgrep - search processes by pattern
[user@host ~]$ pgrep -l http
1234 httpd
1235 httpd

# pgrep with more details
[user@host ~]$ pgrep -a httpd
1234 /usr/sbin/httpd -DFOREGROUND

# lsof - list open files by process
[user@host ~]$ lsof -p 1234 | head

# What process is using a file?
[user@host ~]$ lsof /var/log/messages

# What process is using a port?
[user@host ~]$ lsof -i :80

Beyond ps and top, several other tools help investigate processes. htop is an enhanced version of top with a nicer interface, color coding, and mouse support. It is not installed by default but is available in EPEL. Many administrators prefer it. pidof quickly finds PIDs for a named program. Unlike grepping ps output, it returns just the PIDs, which is useful for scripting. pgrep searches for processes by pattern and has many options. The -l flag includes process names, -a includes full command lines. It is cleaner than ps | grep. lsof (list open files) shows what files a process has open. This is invaluable for understanding what a process is doing and what resources it is using. Since Linux treats everything as a file, lsof also shows network connections, which is how you find what process is using a specific port. lsof -i :80 shows all processes using port 80.

Foreground and Background

Foreground processes receive keyboard input and block the terminal. Background processes run without blocking, freeing the terminal for other work.

# Run command in foreground (default)
[user@host ~]$ sleep 60
# Terminal is blocked for 60 seconds...

# Run command in background (add &)
[user@host ~]$ sleep 60 &
[1] 5800      # [job number] PID
[user@host ~]$ # Terminal available immediately

# Suspend foreground process (Ctrl+Z)
[user@host ~]$ sleep 60
^Z
[1]+  Stopped                 sleep 60

# Resume in background
[user@host ~]$ bg
[1]+ sleep 60 &

# Bring to foreground
[user@host ~]$ fg
sleep 60

Job control lets you manage foreground and background processes from your shell. A foreground process receives keyboard input and its output goes directly to the terminal. While running, it blocks - you cannot type other commands. A background process runs without blocking the terminal. You can continue working while it executes. Output may still appear (which can be confusing), but you can type commands. Adding & at the end of a command runs it in the background immediately. The shell reports the job number in brackets and the PID. Ctrl+Z suspends a running foreground process. It stops executing and becomes a stopped background job. This is not termination - the process still exists and can be resumed. The bg command resumes a stopped job in the background. The fg command brings a background job to the foreground. These let you switch between interactive and background execution for long-running tasks.

Managing Jobs

# List current jobs
[user@host ~]$ jobs
[1]-  Running                 sleep 100 &
[2]+  Stopped                 vim file.txt

# Jobs with PIDs
[user@host ~]$ jobs -l
[1]-  5800 Running                 sleep 100 &
[2]+  5810 Stopped                 vim file.txt

# Bring specific job to foreground
[user@host ~]$ fg %1           # Job number 1
[user@host ~]$ fg %vim         # Job starting with "vim"

# Resume specific job in background
[user@host ~]$ bg %2

# The + and - indicate:
# + current job (default for fg/bg)
# - previous job

# Disown - remove job from shell's job table
[user@host ~]$ disown %1
# Process continues but shell doesn't track it

The jobs command lists jobs managed by your current shell. Each job has a number in brackets, a state, and the command. The + marks the current job - what fg and bg affect by default. The - marks the previous job. jobs -l includes PIDs. This is helpful when you need to reference a job by PID rather than job number for other commands. You can specify jobs with % followed by the job number, or % followed by a command name prefix. fg %2 brings job 2 to foreground. fg %vim brings the job whose command starts with vim. The disown command removes a job from the shell's job table. The process keeps running but the shell no longer tracks it. This is useful if you started something and realize you want it to continue after you log out. Important: jobs are shell-specific. Each terminal has its own job list. Jobs from one terminal are not visible in another.

Keeping Processes Running

Normally, background processes terminate when you log out. Use nohup to keep them running.

# nohup - "no hangup" - ignore SIGHUP signal
[user@host ~]$ nohup long-running-script.sh &
nohup: ignoring input and appending output to 'nohup.out'
[1] 5850

# Output goes to nohup.out (or redirect explicitly)
[user@host ~]$ nohup ./backup.sh > backup.log 2>&1 &

# Now safe to log out - process continues
[user@host ~]$ exit

# Later, check if still running
[user@host ~]$ ps aux | grep backup

# Alternative: screen or tmux for interactive sessions
[user@host ~]$ screen -S mysession
# Work in screen session...
# Detach with Ctrl+A, D
# Reattach later:
[user@host ~]$ screen -r mysession

When you log out, the shell sends SIGHUP (hangup signal) to its child processes, causing them to terminate. This means background processes stop when you disconnect. nohup prevents this. It makes the process immune to SIGHUP, so it continues running after logout. The syntax is nohup followed by the command. Add & to run in background. nohup redirects output to nohup.out by default since the terminal is going away. You can redirect explicitly to choose your own log file. For long-running administrative tasks on remote servers, always use nohup or you will lose your work if the connection drops. For interactive work that needs to survive disconnection, screen or tmux are better alternatives. They create persistent terminal sessions that you can detach from and reattach to later. Install them with dnf if needed. They are invaluable for remote administration.

Understanding Signals

Signals are software interrupts sent to processes. They notify processes of events and can request termination, reload, or other actions.

Signal	Number	Default Action	Description
SIGHUP	1	Terminate	Hangup - terminal closed, often used to reload config
SIGINT	2	Terminate	Interrupt - Ctrl+C pressed
SIGQUIT	3	Core dump	Quit - Ctrl+\ pressed
SIGKILL	9	Terminate	Kill - cannot be caught or ignored, immediate death
SIGTERM	15	Terminate	Terminate - polite request to exit (default for kill)
SIGSTOP	19	Stop	Stop - cannot be caught, pauses process
SIGCONT	18	Continue	Continue - resume stopped process
SIGTSTP	20	Stop	Terminal stop - Ctrl+Z pressed

Key distinction: SIGTERM asks nicely (process can clean up). SIGKILL forces immediately (no cleanup possible).

Signals are the inter-process communication mechanism for controlling processes. Each signal has a name, number, and default action. SIGHUP was originally sent when a terminal disconnected. Now it is commonly used to tell daemons to reload their configuration without restarting. SIGINT is generated by Ctrl+C. It requests graceful termination, and well-written programs will clean up and exit. SIGTERM (signal 15) is the default signal sent by kill. It requests termination, giving the process a chance to clean up - close files, remove temporary files, release resources. SIGKILL (signal 9) is the nuclear option. The kernel immediately terminates the process. The process cannot catch, block, or ignore it. Use only when SIGTERM fails, because the process has no chance to clean up. SIGSTOP and SIGCONT pause and resume processes. SIGSTOP cannot be caught - the process will stop. Ctrl+Z sends SIGTSTP, which can be caught.

Sending Signals: kill

kill sends signals to processes. Despite the name, it can send any signal, not just termination signals.

# Default: send SIGTERM (signal 15)
[root@host ~]# kill 1234

# Specify signal by name
[root@host ~]# kill -SIGTERM 1234
[root@host ~]# kill -TERM 1234

# Specify signal by number
[root@host ~]# kill -15 1234

# Force kill (cannot be caught - use as last resort)
[root@host ~]# kill -9 1234
[root@host ~]# kill -SIGKILL 1234

# Send to multiple processes
[root@host ~]# kill 1234 1235 1236

# List available signals
[user@host ~]$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
 9) SIGKILL     15) SIGTERM     18) SIGCONT     19) SIGSTOP ...

Best practice: Try SIGTERM first. Only use SIGKILL (-9) if SIGTERM fails after a few seconds.

The kill command sends signals to processes. Its name is misleading - while often used to terminate processes, it can send any signal. The default signal is SIGTERM (15), a polite termination request. You specify the signal with -SIGNAME, -NAME, or -NUMBER. All three forms work: kill -SIGTERM, kill -TERM, and kill -15 are equivalent. SIGKILL (-9) forces immediate termination. The process cannot catch or ignore it. However, it also means no cleanup - files might not be closed properly, temporary files not removed, locks not released. Always try SIGTERM first and give the process a few seconds to respond before resorting to SIGKILL. You can specify multiple PIDs to signal several processes at once. kill -l lists all signals with their numbers. You need to know the PID to use kill. Regular users can only signal their own processes. Root can signal any process.

killall and pkill

# killall - kill by exact process name
[root@host ~]# killall httpd
# Sends SIGTERM to all processes named exactly "httpd"

# killall with specific signal
[root@host ~]# killall -9 httpd
[root@host ~]# killall -SIGHUP httpd     # Reload config

# pkill - kill by pattern (more flexible)
[root@host ~]# pkill http
# Matches any process containing "http"

# pkill by user
[root@host ~]# pkill -u student
# Kill all processes owned by student

# pkill with signal
[root@host ~]# pkill -9 -u baduser

# Preview what would be killed (like pgrep)
[user@host ~]$ pgrep -l http
1234 httpd
1235 httpd
# Then: pkill http

Caution: pkill matches patterns - pkill user might kill more than intended. Preview with pgrep first!

killall and pkill save you from looking up PIDs. They signal processes by name or pattern. killall requires an exact process name match. killall httpd affects only processes named exactly httpd. It is safe in that sense but requires you to know the exact name. pkill matches patterns, which is more flexible but more dangerous. pkill http matches httpd, but also myhttp, http-proxy, and anything else containing http. Always preview with pgrep first to see what would be affected. pkill -u is very powerful - it kills all processes owned by a user. Useful for forcing a user off the system, but dangerous if you specify the wrong user. Like kill, both commands send SIGTERM by default. Specify other signals with -SIGNAL or -NUMBER. Both killall and pkill accept multiple match criteria. You can match by user, terminal, and other attributes. The difference between them: killall is simpler (exact names), pkill is more powerful (patterns and multiple criteria).

Process Priority

The Linux scheduler uses nice values to determine CPU priority. Lower nice values = higher priority. Range: -20 (highest) to 19 (lowest).

-20
Highest

→

-10

→

0
Default

→

+10

→

+19
Lowest

# View process nice values (NI column)
[user@host ~]$ ps -eo pid,ni,cmd
  PID  NI CMD
    1   0 /usr/lib/systemd/systemd
 1234   0 /usr/sbin/httpd
 5000  10 /usr/local/bin/backup.sh

# Also visible in top (NI column)
[user@host ~]$ top

Naming: A "nice" process is considerate of others. Higher nice value = nicer = lower priority. Negative = not nice = higher priority.

Linux uses nice values to influence CPU scheduling priority. The name comes from the idea that a nice process is courteous to other processes and does not hog resources. Nice values range from -20 to 19. Zero is the default for normal processes. Negative values increase priority - these processes get more CPU time. Only root can set negative nice values. Positive values decrease priority - these processes yield to others. The scale is counterintuitive: lower numbers mean higher priority. A process with nice -20 is not nice at all - it aggressively wants CPU. A process with nice 19 is very nice - it runs only when nothing else wants the CPU. In ps output, the NI column shows nice value. In top, you see both NI (nice) and PR (priority). Priority is calculated from nice value plus base priority. For most CPU-bound tasks, nice values make a noticeable difference in how much CPU time each process receives.

nice and renice

# Start process with specific nice value
[user@host ~]$ nice -n 10 ./long-task.sh
# Runs with nice value 10 (lower priority)

# Default nice value is 10 if not specified
[user@host ~]$ nice ./long-task.sh

# Only root can set negative nice values
[root@host ~]# nice -n -5 ./important-task.sh

# Change nice value of running process
[root@host ~]# renice -n 15 -p 1234
1234 (process ID) old priority 0, new priority 15

# Renice by user (all processes owned by user)
[root@host ~]# renice -n 10 -u student

# Regular users can only increase nice (lower priority)
[user@host ~]$ renice -n 5 -p 5678      # Works (lowering priority)
[user@host ~]$ renice -n -5 -p 5678     # Fails (raising priority)
renice: failed to set priority for 5678: Permission denied

nice starts a process with a specified nice value. Without a value, it defaults to 10. This is useful for launching background tasks that should not interfere with interactive work. renice changes the nice value of a running process. You can target by PID with -p, by user with -u, or by group with -g. This is useful when you discover a process is consuming too much CPU and want to reduce its impact. Permission rules are important. Regular users can only make processes nicer (increase nice value, lower priority). They cannot make processes less nice (decrease nice value, raise priority). Only root can set negative nice values or decrease any process's nice value. This prevents users from giving their processes unfair advantages. In practice, use nice for backup scripts, batch jobs, and anything CPU-intensive that should yield to interactive use. Use renice to tame a runaway process that is monopolizing CPU without killing it.

Best Practices

Do

Use ps/top to investigate before killing
Try SIGTERM before SIGKILL
Use pgrep to preview pkill targets
Use nohup for long-running tasks
Nice background jobs to reduce impact
Monitor with top for real-time issues
Check process owner before killing
Understand why a process is misbehaving

Do Not

Jump straight to kill -9
Kill processes you don't understand
Use pkill without previewing matches
Kill system processes carelessly
Ignore zombie process accumulation
Assume process names are unique
Forget that kill sends signals, not just kills
Neglect to check if process actually stopped

Troubleshooting order: Investigate (ps, top) → Understand the problem → Try gentle solutions first → Escalate if needed

Good process management requires investigation before action. Always use ps or top to understand what a process is doing before deciding to kill it. A process using high CPU might be doing legitimate work. Try SIGTERM before SIGKILL. Give processes a chance to clean up. Wait a few seconds after SIGTERM before escalating to SIGKILL. Always preview pkill targets with pgrep. Pattern matching can surprise you. pkill java might kill processes you did not intend. Use nohup or screen/tmux for administrative tasks that need to survive disconnection. Otherwise you risk losing work. Nice background and batch jobs appropriately. A backup running at default priority can impact interactive users. Do not kill processes you do not understand. That process using memory might be a critical cache. Killing it might cause bigger problems. Do not ignore zombies - a few are normal, many indicate a problem with the parent process. Verify processes actually stopped after killing. Some processes are stubborn or respawn immediately.

Key Takeaways

Investigate: Use ps aux for snapshots, top for real-time monitoring. Understand PID, state, CPU, memory.

Jobs: Background with &, suspend with Ctrl+Z, resume with bg/fg. Use nohup to survive logout.

Signals: kill PID sends SIGTERM. kill -9 forces. pkill matches patterns. SIGTERM before SIGKILL!

Priority: nice starts with priority, renice changes running process. Range -20 to 19, lower is higher priority.

LAB EXERCISES

Use ps aux to list all processes and identify high CPU users
Monitor system with top, sort by memory, filter by user
Run a process in background, suspend it, and resume in foreground
Use kill to send SIGTERM, then SIGKILL to a test process
Find processes by name with pgrep, terminate with pkill
Start a process with nice, change priority with renice

Next: Controlling Services and Daemons

Let me summarize the key points about process management. For investigation, ps aux gives you a comprehensive snapshot of all processes with CPU and memory usage. top provides continuous real-time monitoring with interactive controls. Understand what the columns mean - PID, state, CPU percentage, memory usage - to quickly assess system health. For job control, add & to run commands in the background. Ctrl+Z suspends the foreground process. bg and fg move jobs between foreground and background. Use nohup for tasks that need to continue after you log out. For signals, kill sends SIGTERM by default - a polite termination request. kill -9 sends SIGKILL, the force option that cannot be ignored. pkill and killall let you signal by name instead of PID. Always try SIGTERM first and escalate to SIGKILL only when necessary. For priority, nice starts processes with adjusted priority, renice changes running processes. Lower nice values mean higher priority. Regular users can only lower priority (increase nice); root can do both. Your lab exercises provide hands-on practice with these essential skills.