OS Lab 3 - Processes and Jobs

This exercise examines the fundamental concepts of execution management within the Linux operating system. It builds upon foundational command-line skills to explore the hierarchical relationship between sessions, process groups, processes, and threads. The lab will cover methods for observing process states, managing concurrent tasks through job control, analyzing the structure of multi-process and multi-threaded applications, and inspecting system resource allocation, such as file descriptors and network sockets.

Objectives

• Upon successful completion of this laboratory exercise, the student will be able to:
• Differentiate between and identify Session IDs (SID), Process Group IDs (PGID), Process IDs (PID), Parent Process IDs (PPID), and Thread IDs (TID/SPID) in standard utility output.
• Describe the primary process states: Running (R), Interruptible Sleep (S), Uninterruptible Sleep (D), Stopped (T), and Zombie (Z).
• Describe the relationship between a controlling terminal, a session, a process group (shell job), a process, and a thread.
• Utilize standard Linux utilities to observe multi-threaded execution within a single process and multiple processes within a single process group (e.g., a command pipeline).
• Explain the concept of process niceness and its effect on CPU scheduling priority.
• Use lsof and fuser to identify which processes have open file descriptors or network sockets.
• Employ shell job control mechanisms (&, jobs, fg, bg, kill) to manage long-running background tasks.

Prerequisites

System Requirements

A running instance of the course-provided Linux virtual machine with SSH or direct terminal access.

Required Packages

The following packages must be installed to complete all sections of this exercise. Execute the commands below to update the package index and install the necessary utilities.

p7zip-full: Provides the 7z utility, which can be used to generate a multi-threaded, CPU-bound workload.

htop, iotop: Advanced, interactive process and I/O monitoring tools.

lsof: A utility to list open files and the processes that opened them.

sudo apt update
sudo apt install -y p7zip-full htop iotop lsof

Theoretical Background

Process Hierarchy and Identifiers

The Linux kernel organizes execution into a strict hierarchy to manage resources and control.

Process (PID): A process is an instance of a running program. It has its own memory space, file descriptors, and other system resources. Each process is assigned a unique Process ID (PID). The process that creates a new process is known as the parent, and its identifier is the Parent Process ID (PPID).

Thread (TID/SPID): A thread is the smallest unit of execution that the kernel scheduler manages. A process can contain one or more threads, all of which share the process's memory space and resources. In Linux, threads are sometimes referred to as light-weight processes. The ps command displays the Thread ID under the SPID or TID column. For a single-threaded process, the PID and TID are identical.

Process Group (PGID): A process group is a collection of one or more processes. This abstraction is primarily used for job control. Signals can be sent to an entire process group at once. Each group has a unique Process Group ID (PGID), which is typically the PID of the first process in the group (the group leader). All processes in a command pipeline share the same PGID.

Session (SID): A session is a collection of one or more process groups associated with a single controlling terminal. When a user logs out, a SIGHUP signal is typically sent to all processes in the session, causing them to terminate. Each session has a unique Session ID (SID).

Process States

A process can exist in several states throughout its lifecycle. The most common are:

R (Running or Runnable): The process is either currently executing on a CPU core or is in a run queue, ready for execution.

S (Interruptible Sleep): The process is waiting for an event to complete, such as I/O from a terminal or the expiration of a timer. It can be interrupted by signals. This is the most common state for idle processes.

D (Uninterruptible Sleep): The process is in a sleep state, typically waiting for a direct hardware I/O operation to complete (e.g., reading from a disk). It cannot be interrupted by signals to prevent data corruption. This state is usually short-lived.

T (Stopped): The process execution has been suspended by a signal, typically SIGTSTP (sent by Ctrl+Z) or SIGSTOP. It can be resumed by a SIGCONT signal.

Z (Zombie): The process has terminated, but its entry in the process table has not yet been removed because its parent process has not yet read its exit status via the wait() system call. The zombie process consumes no resources other than a process table slot.

Job Control

An interactive shell provides mechanisms to manage jobs. A job is a shell's representation of a process group.

Background (&): Appending & to a command starts it as a background job. The shell does not wait for its completion and immediately returns to the user prompt.

Listing (jobs): Lists all active jobs associated with the current shell session.

Foreground (fg %n): Moves job number n from the background to the foreground, reattaching it to the terminal's input/output.

Background (bg %n): Resumes a stopped job n, keeping it running in the background.

Signaling (kill %n): Sends a signal to the process group associated with job number n. By default, this is the SIGTERM signal (graceful termination).

Experimental Procedure

Initial Job Control Familiarization

Execute a long-running command in the background. Note the job number and PID reported by the shell.

sleep 600 &

List the active jobs.

jobs

Bring the job to the foreground, then suspend it using the Ctrl+Z key combination.

fg %1
# Press Ctrl+Z

Resume the suspended job in the background.

bg %1

Terminate the job using its job number.

kill %1

Observing Process Identifiers

Execute the ps command with options to display thread-level information (-L) and custom output format (-o).

ps -L -o sid,pgid,pid,ppid,spid,state,cmd

Observe that all processes spawned from your terminal share the same SID. For single-threaded processes like your shell (bash), the PID and SPID are identical. Deliverable A: Provide 3–6 lines of the output and annotate one full row to label the SID, PGID, PID, PPID, and SPID columns.

Manipulating Process States

Start a background process and observe its initial S state.

sleep 1000 &
ps -L -o pid,spid,state,cmd

Send the SIGTSTP signal to stop the job, placing it in the T state.

kill -TSTP %1
ps -L -o pid,spid,state,cmd

Send the SIGCONT signal to continue the job, returning it to the S state.

kill -CONT %1
ps -L -o pid,spid,state,cmd

Deliverable B: Provide the ps output lines showing the process in the S, then T, then S state. For each state, provide a one-line explanation of what that state signifies.

Observing Multi-threading in a Single Process

Execute a multi-threaded CPU benchmark in the background. The -mmt flag enables multi-threading.

7z b -mmt &

Display the process and thread information for the benchmark.

ps -L -o pgid,pid,ppid,spid,ni,state,cmd

The output will show multiple lines with the same PID but distinct SPIDs. This confirms that the 7z application has spawned multiple execution threads to perform its benchmark, all sharing the same process resources. Deliverable C: Provide a snapshot of the ps output where one PID is associated with multiple SPIDs.

Observing Multiple Processes in a Single Process Group

Execute a pipeline of commands in the background. This pipeline generates continuous output.

yes | tr 'y' 'Y' | dd of=/dev/null &

List the processes associated with this pipeline.

ps -L -o sid,pgid,pid,ppid,spid,state,cmd

Note that the yes, tr, and dd processes each have a unique PID but all share the same PGID. The shell places them in the same process group to allow them to be managed as a single unit via job control. Deliverable D: Provide ps output showing at least two different PIDs that share the same PGID.

Modifying Process Scheduling Priority (Niceness)

Run the same multi-threaded benchmark, but with a modified niceness value. A higher niceness value (range -20 to 19) suggests to the kernel scheduler that the process is lower priority.

nice -n 10 7z b -mmt &

Observe the niceness (NI) column in the ps output.

ps -L -o pid,spid,ni,state,cmd

(Optional) For a dynamic view, run top or htop in another terminal and observe the NI and %CPU columns.

Deliverable E: State the niceness value used and provide one line of ps output showing this value in the ni column.

Inspecting Open Files and Sockets

Start a simple web server in the background. It will listen on TCP port 8000 by default.

python3 -m http.server 8000 &

Use lsof to identify which process is listening on TCP port 8000.

sudo lsof -iTCP:8000 -sTCP:LISTEN

Inspect the file descriptors (FDs) open by your current shell process. $$ is a shell variable that expands to the PID of the current shell.

lsof -p $$ | head

File descriptors are integer handles that a process uses to refer to open files, sockets, or other I/O resources. FDs 0, 1, and 2 correspond to standard input, standard output, and standard error, respectively. Deliverable F: Provide the output that identifies the PID holding TCP port 8000, and one line from the lsof -p $$ output showing an open file descriptor.

Use Case: Diagnosing a "Target is busy" Unmount Error

If not already present from a previous lab, create and mount a loopback filesystem.

These commands are for context; reuse your existing setup if possible.

dd if=/dev/zero of=loop.img bs=1M count=100

mkfs.ext4 loop.img

sudo mkdir -p /mnt/labfs

sudo mount loop.img /mnt/labfs

Induce a "busy" state. The simplest method is to change the current working directory of a process to be inside the mount point. Open a new terminal or use your existing one.

cd /mnt/labfs

In a different terminal, attempt to unmount the filesystem. This will fail.

sudo umount /mnt/labfs

Use fuser or lsof to identify the process that is preventing the unmount.

• Using fuser:

fuser -vm /mnt/labfs

• Using lsof:

sudo lsof +D /mnt/labfs

Deliverable G: Provide the command and output that identified the conflicting process. In one sentence, explain why the umount operation failed, referencing the information from the command's output.

Conclusion Questions

Provide concise answers to the following questions:

1. Define the following terms in the context of a Linux operating system: SID, PGID, PID, and SPID.
2. For each process state (R, S, D, T, Z), provide one realistic scenario or cause. Explain what makes the D and Z states unique compared to the others.
3. Describe the effect of the nice -n 10 command on the scheduling priority of the 7z process as observed in the ps output.
4. State one functional difference between the top and htop utilities, based on observation during the benchmark task, or, if there was no observable difference, explain why there was none.

Deliverables and Assessment

Submit a single document containing the outputs and answers for the following items.

Deliverable A: Annotated ps output showing SID, PGID, PID, PPID, and SPID from section #Observing Process Identifiers.

Deliverable B: Three ps output lines and explanations for the S, T, and S process states from section #Manipulating Process States.

Deliverable C: ps output showing a single PID with multiple SPIDs from section #Observing Multi-threading in a Single Process.

Deliverable D: ps output showing multiple PIDs with a common PGID from section #Observing Multiple Processes in a Single Process Group.

Deliverable E: The niceness value used and the corresponding ps output from section #Modifying Process Scheduling Priority (Niceness).

Deliverable F: Proof of PID holding TCP port 8000 and one line showing a file descriptor from section #Inspecting Open Files and Sockets.

Deliverable G: The command and output identifying the process preventing unmount, and a one-sentence explanation from section #Use Case: Diagnosing a "Target is busy" Unmount Error.

Conclusion Questions: Answer the questions in section #Conclusion Questions.