OS Lab 3 - Processes and Jobs - Revizia istoricului

Vserbu: /* Conclusion Questions */

2025-10-17T13:32:48Z

Conclusion Questions

Vserbu: /* Use Case: Diagnosing a "Target is busy" Unmount Error */

2025-10-17T13:31:32Z

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

Vserbu la 17 octombrie 2025 13:29

2025-10-17T13:29:13Z

Vserbu la 17 octombrie 2025 13:28

2025-10-17T13:28:04Z

Vserbu: Pagină nouă: This exercise examines the fundamental concepts of execution management within the Linux operating system. It builds upon foundational command-line skills to explore the hierarchic...

2025-10-17T13:26:22Z

Pagină nouă: This exercise examines the fundamental concepts of execution management within the Linux operating system. It builds upon foundational command-line skills to explore the hierarchic...

Pagină nouă

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 <code>lsof</code> and <code>fuser</code> to identify which processes have open file descriptors or network sockets.
* Employ shell job control mechanisms (<code>&</code>, <code>jobs</code>, <code>fg</code>, <code>bg</code>, <code>kill</code>) 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.

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

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

<code>lsof</code>: A utility to list open files and the processes that opened them.

<syntaxhighlight lang="bash">
sudo apt update
sudo apt install -y p7zip-full htop iotop lsof
</syntaxhighlight>

== 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 <code>ps</code> command displays the '''Thread ID''' under the <code>SPID</code> or <code>TID</code> 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 <code>SIGHUP</code> 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 <code>SIGTSTP</code> (sent by Ctrl+Z) or <code>SIGSTOP</code>. It can be resumed by a <code>SIGCONT</code> 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 <code>wait()</code> 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 (<code>&</code>):''' Appending <code>&</code> 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 (<code>jobs</code>):''' Lists all active jobs associated with the current shell session.

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

'''Background (<code>bg %n</code>):''' Resumes a stopped job <code>n</code>, keeping it running in the background.

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

== Experimental Procedure ==

=== Initial Job Control Familiarization ===
'''Objective:''' To practice the basic job control commands.

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

<syntaxhighlight lang="bash">
sleep 600 &
</syntaxhighlight>

List the active jobs.

<syntaxhighlight lang="bash">
jobs
</syntaxhighlight>

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

<syntaxhighlight lang="bash">
fg %1
# Press Ctrl+Z
</syntaxhighlight>

Resume the suspended job in the background.

<syntaxhighlight lang="bash">
bg %1
</syntaxhighlight>

Terminate the job using its job number.

<syntaxhighlight lang="bash">
kill %1
</syntaxhighlight>

=== Observing Process Identifiers ===
'''Objective:''' To examine the full hierarchy of process identifiers for the current session.

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

<syntaxhighlight lang="bash">
ps -L -o sid,pgid,pid,ppid,spid,state,cmd
</syntaxhighlight>
'''Analysis:''' Observe that all processes spawned from your terminal share the same <code>SID</code>. For single-threaded processes like your shell (<code>bash</code>), the <code>PID</code> and <code>SPID</code> are identical.
'''Deliverable A:''' Provide 3–6 lines of the output and annotate one full row to label the <code>SID</code>, <code>PGID</code>, <code>PID</code>, <code>PPID</code>, and <code>SPID</code> columns.

=== Manipulating Process States ===
'''Objective:''' To create and observe the <code>S</code> (Sleep), <code>T</code> (Stopped), and <code>S</code> (resumed Sleep) states.

Start a background process and observe its initial <code>S</code> state. The <code>[s]leep</code> pattern in <code>grep</code> prevents the <code>grep</code> process itself from appearing in the output.

<syntaxhighlight lang="bash">
sleep 1000 &
ps -L -o pid,spid,state,cmd | grep '[s]leep'
</syntaxhighlight>

Send the <code>SIGTSTP</code> signal to stop the job, placing it in the <code>T</code> state.

<syntaxhighlight lang="bash">
kill -TSTP %1
ps -L -o pid,spid,state,cmd | grep '[s]leep'
</syntaxhighlight>

Send the <code>SIGCONT</code> signal to continue the job, returning it to the <code>S</code> state.

<syntaxhighlight lang="bash">
kill -CONT %1
ps -L -o pid,spid,state,cmd | grep '[s]leep'
</syntaxhighlight>
'''Deliverable B:''' Provide the <code>ps</code> output lines showing the process in the <code>S</code>, then <code>T</code>, then <code>S</code> state. For each state, provide a one-line explanation of what that state signifies.

=== Observing Multi-threading in a Single Process ===
'''Objective:''' To observe multiple threads (TIDs) operating under a single process (PID).

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

<syntaxhighlight lang="bash">
7z b -mmt &
</syntaxhighlight>

Display the process and thread information for the benchmark.

<syntaxhighlight lang="bash">
ps -L -o pgid,pid,ppid,spid,ni,state,cmd | grep '[7]z b'
</syntaxhighlight>
'''Analysis:''' The output will show multiple lines with the same <code>PID</code> but distinct <code>SPID</code>s. This confirms that the <code>7z</code> application has spawned multiple execution threads to perform its benchmark, all sharing the same process resources.
'''Deliverable C:''' Provide a snapshot of the <code>ps</code> output where one PID is associated with multiple SPIDs.

=== Observing Multiple Processes in a Single Process Group ===
'''Objective:''' To demonstrate that a command pipeline constitutes a single job (one PGID) composed of multiple distinct processes (PIDs).

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

<syntaxhighlight lang="bash">
yes | tr 'y' 'Y' | dd of=/dev/null &
</syntaxhighlight>

List the processes associated with this pipeline.

<syntaxhighlight lang="bash">
ps -L -o sid,pgid,pid,ppid,spid,state,cmd | egrep 'yes |tr |dd '
</syntaxhighlight>
'''Analysis:''' Note that the <code>yes</code>, <code>tr</code>, and <code>dd</code> processes each have a unique <code>PID</code> but all share the same <code>PGID</code>. 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 <code>ps</code> output showing at least two different PIDs that share the same PGID.

=== Modifying Process Scheduling Priority (Niceness) ===
'''Objective:''' To alter and observe a process's scheduling priority.

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.

<syntaxhighlight lang="bash">
nice -n 10 7z b -mmt &
</syntaxhighlight>

Observe the niceness (<code>NI</code>) column in the <code>ps</code> output.

<syntaxhighlight lang="bash">
ps -L -o pid,spid,ni,state,cmd | grep '[7]z b'
</syntaxhighlight>

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

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

=== Inspecting Open Files and Sockets ===
'''Objective:''' To identify which process is holding a specific network port or file descriptor.

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

<syntaxhighlight lang="bash">
python3 -m http.server 8000 &
</syntaxhighlight>

Use <code>lsof</code> to identify which process is listening on TCP port 8000.

<syntaxhighlight lang="bash">
sudo lsof -iTCP:8000 -sTCP:LISTEN
</syntaxhighlight>

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

<syntaxhighlight lang="bash">
lsof -p $$ | head
</syntaxhighlight>
'''Analysis:''' 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 <code>lsof -p $$</code> output showing an open file descriptor.

=== Use Case: Diagnosing a "Target is busy" Unmount Error ===
'''Objective:''' To apply file inspection utilities to resolve a common system administration problem.

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

<syntaxhighlight lang="bash">

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

</syntaxhighlight>

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.

<syntaxhighlight lang="bash">
cd /mnt/labfs
</syntaxhighlight>

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

<syntaxhighlight lang="bash">
sudo umount /mnt/labfs
</syntaxhighlight>

Use <code>fuser</code> or <code>lsof</code> to identify the process that is preventing the unmount.

#* Using <code>fuser</code>:
<syntaxhighlight lang="bash">
fuser -vm /mnt/labfs
</syntaxhighlight>
#* Using <code>lsof</code>:
<syntaxhighlight lang="bash">
sudo lsof +D /mnt/labfs
</syntaxhighlight>
'''Deliverable G:''' Provide the command and output that identified the conflicting process. In one sentence, explain why the <code>umount</code> operation failed, referencing the information from the command's output.

== Conclusion Questions ==

Provide concise answers to the following questions:

# Define the following terms in the context of a Linux operating system: SID, PGID, PID, and SPID.
# 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.
# Describe the effect of the <code>nice -n 10</code> command on the scheduling priority of the <code>7z</code> process as observed in the <code>ps</code> output.
# State one functional difference between the <code>top</code> and <code>htop</code> utilities, based on observation during the benchmark task.

== Deliverables and Assessment ==

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

'''Deliverable A:''' Annotated <code>ps</code> output showing SID, PGID, PID, PPID, and SPID from section [[#Observing Process Identifiers]].

'''Deliverable B:''' Three <code>ps</code> output lines and explanations for the S, T, and S process states from section [[#Manipulating Process States]].

'''Deliverable C:''' <code>ps</code> output showing a single PID with multiple SPIDs from section [[#Observing Multi-threading in a Single Process]].

'''Deliverable D:''' <code>ps</code> 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 <code>ps</code> 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]].

@@ Linia 253: / Linia 253: @@
 # 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.
 # Describe the effect of the <code>nice -n 10</code> command on the scheduling priority of the <code>7z</code> process as observed in the <code>ps</code> output.
-# State one functional difference between the <code>top</code> and <code>htop</code> utilities, based on observation during the benchmark task.
+# State one functional difference between the <code>top</code> and <code>htop</code> utilities, based on observation during the benchmark task, or, if there was no observable difference, explain why there was none.
 == Deliverables and Assessment ==

@@ Linia 236: / Linia 236: @@
 Use <code>fuser</code> or <code>lsof</code> to identify the process that is preventing the unmount.
-#* Using <code>fuser</code>:
+* Using <code>fuser</code>:
 <syntaxhighlight lang="bash">
 fuser -vm /mnt/labfs
 </syntaxhighlight>
-#* Using <code>lsof</code>:
+* Using <code>lsof</code>:
 <syntaxhighlight lang="bash">
 sudo lsof +D /mnt/labfs
 </syntaxhighlight>
 '''Deliverable G:''' Provide the command and output that identified the conflicting process. In one sentence, explain why the <code>umount</code> operation failed, referencing the information from the command's output.
 == Conclusion Questions ==

@@ Linia 115: / Linia 115: @@
 === Manipulating Process States ===
-Start a background process and observe its initial <code>S</code> state. The <code>[s]leep</code> pattern in <code>grep</code> prevents the <code>grep</code> process itself from appearing in the output.
+Start a background process and observe its initial <code>S</code> state.
 <syntaxhighlight lang="bash">
 sleep 1000 &
-ps -L -o pid,spid,state,cmd | grep '[s]leep'
+ps -L -o pid,spid,state,cmd
 </syntaxhighlight>
@@ Linia 126: / Linia 126: @@
 <syntaxhighlight lang="bash">
 kill -TSTP %1
-ps -L -o pid,spid,state,cmd | grep '[s]leep'
+ps -L -o pid,spid,state,cmd
 </syntaxhighlight>
@@ Linia 133: / Linia 133: @@
 <syntaxhighlight lang="bash">
 kill -CONT %1
-ps -L -o pid,spid,state,cmd | grep '[s]leep'
+ps -L -o pid,spid,state,cmd
 </syntaxhighlight>
 '''Deliverable B:''' Provide the <code>ps</code> output lines showing the process in the <code>S</code>, then <code>T</code>, then <code>S</code> state. For each state, provide a one-line explanation of what that state signifies.
@@ Linia 147: / Linia 147: @@
 <syntaxhighlight lang="bash">
-ps -L -o pgid,pid,ppid,spid,ni,state,cmd | grep '[7]z b'
+ps -L -o pgid,pid,ppid,spid,ni,state,cmd
 </syntaxhighlight>
 The output will show multiple lines with the same <code>PID</code> but distinct <code>SPID</code>s. This confirms that the <code>7z</code> application has spawned multiple execution threads to perform its benchmark, all sharing the same process resources.
@@ Linia 162: / Linia 162: @@
 <syntaxhighlight lang="bash">
-ps -L -o sid,pgid,pid,ppid,spid,state,cmd | egrep 'yes |tr |dd '
+ps -L -o sid,pgid,pid,ppid,spid,state,cmd
 </syntaxhighlight>
 Note that the <code>yes</code>, <code>tr</code>, and <code>dd</code> processes each have a unique <code>PID</code> but all share the same <code>PGID</code>. The shell places them in the same process group to allow them to be managed as a single unit via job control.
@@ Linia 177: / Linia 177: @@
 <syntaxhighlight lang="bash">
-ps -L -o pid,spid,ni,state,cmd | grep '[7]z b'
+ps -L -o pid,spid,ni,state,cmd
 </syntaxhighlight>

@@ Linia 74: / Linia 74: @@
 === Initial Job Control Familiarization ===
 Execute a long-running command in the background. Note the job number and PID reported by the shell.
@@ Linia 108: / Linia 106: @@
 === Observing Process Identifiers ===
 Execute the <code>ps</code> command with options to display thread-level information (<code>-L</code>) and custom output format (<code>-o</code>).
@@ Linia 115: / Linia 111: @@
 ps -L -o sid,pgid,pid,ppid,spid,state,cmd
 </syntaxhighlight>
-'''Analysis:''' Observe that all processes spawned from your terminal share the same <code>SID</code>. For single-threaded processes like your shell (<code>bash</code>), the <code>PID</code> and <code>SPID</code> are identical.
+Observe that all processes spawned from your terminal share the same <code>SID</code>. For single-threaded processes like your shell (<code>bash</code>), the <code>PID</code> and <code>SPID</code> are identical.
 '''Deliverable A:''' Provide 3–6 lines of the output and annotate one full row to label the <code>SID</code>, <code>PGID</code>, <code>PID</code>, <code>PPID</code>, and <code>SPID</code> columns.
 === Manipulating Process States ===
 Start a background process and observe its initial <code>S</code> state. The <code>[s]leep</code> pattern in <code>grep</code> prevents the <code>grep</code> process itself from appearing in the output.
@@ Linia 144: / Linia 138: @@
 === Observing Multi-threading in a Single Process ===
 Execute a multi-threaded CPU benchmark in the background. The <code>-mmt</code> flag enables multi-threading.
@@ Linia 157: / Linia 149: @@
 ps -L -o pgid,pid,ppid,spid,ni,state,cmd | grep '[7]z b'
 </syntaxhighlight>
-'''Analysis:''' The output will show multiple lines with the same <code>PID</code> but distinct <code>SPID</code>s. This confirms that the <code>7z</code> application has spawned multiple execution threads to perform its benchmark, all sharing the same process resources.
+The output will show multiple lines with the same <code>PID</code> but distinct <code>SPID</code>s. This confirms that the <code>7z</code> application has spawned multiple execution threads to perform its benchmark, all sharing the same process resources.
 '''Deliverable C:''' Provide a snapshot of the <code>ps</code> 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.
@@ Linia 174: / Linia 164: @@
 ps -L -o sid,pgid,pid,ppid,spid,state,cmd | egrep 'yes |tr |dd '
 </syntaxhighlight>
-'''Analysis:''' Note that the <code>yes</code>, <code>tr</code>, and <code>dd</code> processes each have a unique <code>PID</code> but all share the same <code>PGID</code>. The shell places them in the same process group to allow them to be managed as a single unit via job control.
+Note that the <code>yes</code>, <code>tr</code>, and <code>dd</code> processes each have a unique <code>PID</code> but all share the same <code>PGID</code>. 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 <code>ps</code> 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.
@@ Linia 197: / Linia 185: @@
 === Inspecting Open Files and Sockets ===
 Start a simple web server in the background. It will listen on TCP port 8000 by default.
@@ Linia 216: / Linia 202: @@
 lsof -p $$ | head
 </syntaxhighlight>
-'''Analysis:''' 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.
+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 <code>lsof -p $$</code> 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.