Unit 8: Process Management - Subjective Questions

A process is an instance of a program that is currently being executed by the operating system. It is an active entity that includes the program code, its current activity (represented by the program counter), and a set of associated resources.

Key differences between a Process and a Program:

• Nature:
  • A program is a passive entity — a set of instructions stored on disk (an executable file).
  • A process is an active entity — a program in execution loaded into memory.
• Lifetime:
  • A program exists permanently until deleted.
  • A process exists only during execution and terminates when execution completes.
• Resources:
  • A program does not consume system resources while stored.
  • A process actively consumes CPU time, memory, registers, and I/O resources.
• Multiplicity:
  • A single program can spawn multiple processes (e.g., opening multiple instances of a text editor).

In summary, a program becomes a process when it is loaded into memory and begins execution.

A process passes through several states during its lifetime. The primary process states are:

• New: The process is being created.
• Ready: The process is loaded into main memory and waiting to be assigned to the CPU.
• Running: Instructions of the process are being executed by the CPU.
• Waiting (Blocked): The process is waiting for some event to occur (e.g., I/O completion).
• Terminated: The process has finished execution and is removed from memory.

State Transitions:

• New → Ready: Process admitted to the ready queue.
• Ready → Running: Scheduler dispatches the process to the CPU.
• Running → Ready: Process is preempted (time quantum expires).
• Running → Waiting: Process requests I/O or waits for an event.
• Waiting → Ready: The awaited event completes.
• Running → Terminated: Process completes execution.

This cyclic movement allows efficient CPU utilization through multiprogramming, ensuring the processor is never idle when work is available.

A Process ID (PID) is a unique numerical identifier assigned by the operating system kernel to every process running on the system.

Significance of PID:

• Unique Identification: Each active process is uniquely identified by its PID, allowing the kernel and users to reference it.
• Process Control: Commands like kill, renice, and wait use the PID to target specific processes.
• Process Tracking: Utilities like ps and top display PIDs for monitoring.

How PIDs are assigned:

• PIDs are assigned sequentially by the kernel as processes are created.
• PID 1 is always assigned to the init (or systemd) process, the first process started at boot.
• PID 0 typically refers to the scheduler/swapper kernel process.
• When PIDs reach the system maximum, the counter wraps around and reuses freed (dead) PIDs.
• A child process can obtain its Parent Process ID using the PPID.

In shell scripting, the special variable $$ returns the PID of the current shell, and $! returns the PID of the last background process.

The ps (process status) command displays information about currently running processes as a snapshot at the moment the command is executed.

Basic syntax:

ps [options]

Commonly used options:

• ps — Shows processes for the current shell only.
• ps -e or ps -A — Displays all processes running on the system.
• ps -f — Full-format listing (shows UID, PID, PPID, C, STIME, TTY, TIME, CMD).
• ps -ef — Combines all processes with full-format details (very common).
• ps aux — BSD-style output showing user, %CPU, %MEM, VSZ, RSS, and command.
• ps -u username — Lists processes owned by a specific user.
• ps -p PID — Displays information for a specific PID.

Example:

ps -ef | grep firefox

This lists all processes and filters those related to firefox.

Key columns explained:

• PID: Process ID
• PPID: Parent Process ID
• TTY: Terminal associated with the process
• TIME: Cumulative CPU time used
• CMD: Command that started the process

The top command provides a dynamic, real-time view of the running system, continuously updating information about processes and overall resource usage.

How it helps:

• Displays live CPU and memory usage.
• Identifies resource-hungry processes.
• Allows interactive process management (killing, renicing) directly from the interface.

Summary (Header) fields:

• uptime: How long the system has been running.
• load average: System load over 1, 5, and 15 minutes.
• Tasks: Total, running, sleeping, stopped, and zombie processes.
• %Cpu(s): Breakdown of CPU usage (us=user, sy=system, id=idle, wa=I/O wait).
• Mem / Swap: Total, used, and free memory.

Per-process columns:

• PID: Process ID
• USER: Owner of the process
• PR / NI: Priority and Nice value
• %CPU: CPU usage percentage
• %MEM: Memory usage percentage
• TIME+: Total CPU time used
• COMMAND: Command name

Interactive keys inside top:

• k — Kill a process (prompts for PID).
• r — Renice a process.
• M — Sort by memory usage.
• P — Sort by CPU usage.
• q — Quit.

Both ps and top are used to monitor processes, but they differ significantly in behavior and usage.

Summary:

• Use ps when you need a one-time snapshot or want to pipe output into scripts (e.g., ps -ef | grep).
• Use top when you need continuous, live monitoring of system performance and interactive control over processes.

In shell terminology, a job is a process (or a group of processes/pipeline) started from and managed by a particular shell session. Jobs can run in the foreground or background.

The jobs command:

The jobs command lists all jobs that are running or stopped in the current shell session, along with their job numbers and states.

Syntax:

jobs [options]

Common options:

• jobs -l — Shows job numbers along with their PIDs.
• jobs -r — Shows only running jobs.
• jobs -s — Shows only stopped jobs.

Example:

$ sleep 300 &
[1] 4521
$ sleep 500 &
[2] 4522
$ jobs
[1]-  Running    sleep 300 &
[2]+  Running    sleep 500 &

Interpreting the output:

• [1], [2] — Job numbers used with fg, bg, and kill.
• + — Indicates the current (default) job.
• - — Indicates the previous job.
• State — Running or Stopped.

Foreground process:

• A process that runs in the terminal and occupies it, preventing other commands from being entered until it completes.
• It receives keyboard input directly.

Background process:

• A process that runs behind the scenes, freeing the terminal for other commands.
• Started by appending an ampersand & to the command.

The bg command:

Resumes a stopped job and runs it in the background.

$ sleep 300      # running in foreground
^Z               # press Ctrl+Z to suspend it
[1]+  Stopped    sleep 300
$ bg %1          # resume job 1 in background
[1]+ sleep 300 &

The fg command:

Brings a background or stopped job into the foreground.

$ fg %1          # bring job 1 to foreground
sleep 300

Key points:

• Ctrl+Z suspends the current foreground job.
• & starts a command directly in the background.
• %n refers to job number n in fg and bg.

The kill command is used to send signals to processes, most commonly to terminate them. Despite its name, kill can send any signal, not just termination signals.

Syntax:

kill [signal] PID

Common signals:

• SIGTERM (15) — Default signal; requests graceful termination, allowing cleanup.
• SIGKILL (9) — Forcefully terminates a process immediately; cannot be caught or ignored.
• SIGHUP (1) — Hangup; often used to reload configuration.
• SIGINT (2) — Interrupt (equivalent to Ctrl+C).
• SIGSTOP (19) — Suspends the process.
• SIGCONT (18) — Resumes a stopped process.

Examples:

kill 4521          # sends default SIGTERM to PID 4521
kill -9 4521       # forcefully kills PID 4521
kill -SIGKILL 4521 # same as above using signal name
kill -l            # lists all available signals

Best practice:

• Always try SIGTERM (15) first to allow graceful shutdown.
• Use SIGKILL (9) only when a process is unresponsive, as it does not allow cleanup and may cause data loss.

The pkill command sends signals to processes based on their name and other attributes rather than their PID.

Syntax:

pkill [options] pattern

Examples:

pkill firefox           # kills all processes named firefox
pkill -9 chrome         # forcefully kills all chrome processes
pkill -u john           # kills all processes owned by user john
pkill -f "python app.py"  # matches against the full command line

Difference between kill and pkill:

Caution:

• pkill can accidentally terminate multiple processes matching the pattern, so patterns should be specific.
• Use pgrep first to preview which processes will be matched before running pkill.

Both commands send signals to processes but use different targeting mechanisms.

kill:

• Targets processes by their PID (Process ID).
• Requires the exact numerical PID.
• Ideal when you know the specific process you want to signal.

pkill:

• Targets processes by name, user, or other attributes using pattern matching.
• Can signal multiple processes simultaneously.
• Ideal when you don't know the PID but know the process name.

Comparison Table:

When to prefer:

• Use kill for precise control over a single, known process.
• Use pkill for convenience when terminating all instances of a named application (e.g., all hung browser tabs).

Zombie Process:

• A zombie (defunct) process is one that has completed execution but still has an entry in the process table.
• This occurs because the process's exit status has not yet been read by its parent using wait().
• Zombies consume no CPU or memory but occupy a PID slot.
• In ps output, they appear with state Z and are marked <defunct>.
• Handling: The parent must call wait() to reap the child. If a parent fails to do so, accumulated zombies can be cleared only when the parent is killed (reparenting to init, which reaps them).

Orphan Process:

• An orphan is a process whose parent has terminated while the child is still running.
• Orphans are automatically adopted by the init (PID 1) or systemd process.
• init then becomes responsible for reaping the orphan when it terminates, preventing it from becoming a permanent zombie.

Key difference:

• A zombie is dead but not reaped; an orphan is alive but has lost its parent.
• Zombies are a resource concern (PID exhaustion in extreme cases), while orphans are handled gracefully by the OS.

Priority:

• Every process has a scheduling priority that determines how much CPU time it receives relative to others.
• Lower priority numbers generally mean higher scheduling importance.

Nice Value:

• The nice value (NI) is a user-space mechanism to influence a process's priority.
• It ranges from -20 (highest priority) to +19 (lowest priority).
• A higher nice value means the process is "nicer" to others, yielding CPU time.
• Default nice value is 0.

Modifying nice values:

• nice — Start a process with a specified nice value:

nice -n 10 ./myscript.sh

• renice — Change the nice value of a running process:

renice -n 5 -p 4521

Important points:

• Only the superuser (root) can assign negative nice values (raising priority).
• Normal users can only lower priority (increase nice value).
• The nice value is visible in the NI column of top and ps.

This mechanism allows administrators to balance CPU allocation among competing processes.

Shell job control allows a user to manage multiple tasks from a single terminal. Here is a complete workflow:

1. Starting a job in the background:

$ sleep 600 &
[1] 7890

The `&` runs the job in the background; `[1]` is the job number and `7890` is the PID.

2. Starting a job in the foreground and suspending it:

$ sleep 600
^Z                       # Ctrl+Z suspends the job
[1]+  Stopped   sleep 600

3. Resuming a suspended job in the background:

$ bg %1
[1]+ sleep 600 &

4. Bringing a background job to the foreground:

$ fg %1
sleep 600

5. Listing jobs:

$ jobs -l
[1]+ 7890 Running   sleep 600 &

6. Terminating a job:

$ kill %1          # using job number
$ kill 7890        # using PID

Summary of control keys:

• & — Run in background.
• Ctrl+Z — Suspend foreground job.
• Ctrl+C — Terminate foreground job (SIGINT).
• bg / fg — Move jobs between background and foreground.

Understanding when to use foreground versus background execution is essential for efficient shell usage.

Trade-offs:

• Foreground advantages: Easy interaction, immediate feedback, simple to terminate with Ctrl+C.
• Foreground disadvantages: Blocks the terminal until completion.
• Background advantages: Allows multitasking, ideal for long jobs like compilation or downloads.
• Background disadvantages: Output can interfere with terminal; requires redirection (e.g., > output.log 2>&1); harder to interact with.

Best practice: Run long, non-interactive tasks in the background with output redirected, while reserving the foreground for interactive commands.

A Process Control Block (PCB) is a data structure maintained by the operating system for every process. It stores all the information needed to manage and control that process.

Information contained in a PCB:

• Process ID (PID): Unique identifier of the process.
• Process State: Current state (new, ready, running, waiting, terminated).
• Program Counter: Address of the next instruction to execute.
• CPU Registers: Contents of all process-related registers.
• CPU Scheduling Information: Priority, scheduling queue pointers, nice value.
• Memory Management Information: Page tables, segment tables, base/limit registers.
• Accounting Information: CPU time used, time limits, process numbers.
• I/O Status Information: List of open files and allocated I/O devices.

Importance of the PCB:

• Context Switching: During a context switch, the state of the running process is saved into its PCB, and the state of the next process is loaded from its PCB.
• Process Management: Enables the OS to track, suspend, resume, and terminate processes accurately.
• Resource Tracking: Keeps records of resources assigned to each process.

The PCB is thus the backbone of process management, making multiprogramming and multitasking possible.

In Unix/Linux, new processes are created through a combination of the fork() and exec() system calls.

The fork() system call:

• Creates a new (child) process that is an almost exact copy of the parent process.
• The child gets a new unique PID, while inheriting the parent's code, data, and open files.
• Return values:
  • Returns 0 to the child process.
  • Returns the child's PID to the parent process.
  • Returns -1 on failure.

The exec() family of calls:

• Replaces the current process image with a new program.
• The PID remains the same, but the code, data, and stack are replaced.
• Common variants: execl(), execv(), execlp(), execvp().

Typical creation pattern:

1. Parent calls fork() to create a child.
2. The child calls exec() to load and run a new program.
3. The parent may call wait() to wait for the child to finish and reap it.

Example flow (conceptual):

pid = fork();
if (pid == 0) {
    execvp("ls", args);   // child runs 'ls'
} else {
    wait(NULL);           // parent waits
}

This fork-exec model cleanly separates process creation from program loading, giving great flexibility.

Here is a systematic approach to diagnose and terminate a runaway process:

Step 1 — Identify the offending process:

Use top to observe real-time CPU usage:

top

Press **`P`** to sort by CPU usage; the `dataproc` process will appear near the top with its PID and %CPU.

Step 2 — Find the exact PID:

Alternatively, use ps with filtering:

ps -ef | grep dataproc

or use `pgrep`:

bash
pgrep -l dataproc

Step 3 — Attempt graceful termination:

Send the default SIGTERM (15) to allow cleanup:

kill 8123          # replace with actual PID

Step 4 — Verify termination:

ps -p 8123

If no output, the process ended successfully.

Step 5 — Force kill if unresponsive:

If the process ignores SIGTERM, use SIGKILL (9):

kill -9 8123

or kill all instances by name:

bash
pkill -9 dataproc

Step 6 — Confirm resource recovery:

Return to top to confirm CPU usage has normalized.

Best practice: Always try graceful termination first; use kill -9 only as a last resort to avoid data corruption.

Context Switching is the mechanism by which the CPU switches from executing one process (or thread) to another, enabling multitasking.

Why it is needed:

• Allows multiple processes to share a single CPU.
• Occurs during interrupts, system calls, time-slice expiry, or when a process blocks for I/O.

Steps involved in a context switch:

1. Save state: The current process's context (program counter, CPU registers, state) is saved into its PCB.
2. Update PCB: The state of the outgoing process is updated (e.g., to Ready or Waiting).
3. Select next process: The scheduler selects the next process from the ready queue.
4. Load state: The saved context of the selected process is loaded from its PCB into the CPU.
5. Resume execution: The CPU resumes the new process from where it left off.

Overhead of context switching:

• Context switching is pure overhead — no useful user work is done during the switch.
• Costs include saving/loading registers, updating memory maps, and flushing CPU caches/TLB.
• Excessive context switching (thrashing) degrades performance.

Reducing overhead:

• Efficient scheduling algorithms.
• Larger time quanta (with trade-offs in responsiveness).
• Hardware support for fast state saving.

Thus context switching is essential for concurrency but must be minimized to maintain efficiency.

Signals are software interrupts used by the operating system to notify a process that an event has occurred. They are a fundamental inter-process communication and control mechanism.

Common signals:

• SIGHUP (1) — Hangup; terminal closed or reload configuration.
• SIGINT (2) — Interrupt from keyboard (Ctrl+C).
• SIGQUIT (3) — Quit from keyboard (Ctrl+\), generates core dump.
• SIGKILL (9) — Forcefully kills a process; cannot be caught or ignored.
• SIGTERM (15) — Requests graceful termination (default for kill).
• SIGSTOP (19) — Suspends a process; cannot be caught or ignored.
• SIGCONT (18) — Resumes a stopped process.
• SIGSEGV (11) — Invalid memory reference (segmentation fault).

How processes respond to signals:

• Default action: Each signal has a predefined default (e.g., terminate, ignore, stop).
• Catch/Handle: A process can register a signal handler function to execute custom code when a catchable signal is received.
• Ignore: A process can choose to ignore certain signals (except SIGKILL and SIGSTOP).
• Block: Signals can be temporarily blocked (masked) and delivered later.

Uncatchable signals:

• SIGKILL (9) and SIGSTOP (19) cannot be caught, blocked, or ignored, guaranteeing the OS can always terminate or stop a process.

Sending signals:

kill -SIGTERM 4521    # graceful
kill -9 4521          # force kill
kill -l               # list all signals

Signals thus provide a flexible way to control process behavior and enable robust process management.