 Hello everyone, myself Mr. F. R. Syed. I work as an assistant professor in the department of computer science and engineering at Walsh Institute of Technology, Saulapur. The topic for my today's lecture is process termination in Unix system. So, let us see what all happens when a process terminates in Unix, the learning outcome. At the end of the session the students will be able to describe the concept of process termination in Unix system. Okay, now let us see the process termination. The processes on a Unix system terminate by executing the exit system call. An exiting process enters the zombie state, relinquishes its resources and dismantles its context except for its slot in the process table. Now the syntax for the call is exit into bracket the status where the value of status is returned to the parent process for its examination. Okay, the processes may call exit either explicitly or implicitly at the end of a program meaning the exit system call is either called explicitly or implicitly at the end of a program. The startup routine linked with all the C programs calls the exit when the program returns from the main function which is nothing but the entry point of all the programs. Now alternatively the kernel may invoke exit internally for a process on receiving uncut signals. Now in that case the value of the status is the signal number. Now the system imposes no time limit on the execution of a process and processes frequently exist for a longer period of time. So let us see some examples. We have process 0 that is the swapper process and process 1 that is nothing but the init process. So these exist throughout the lifetime of a system. Now there are other examples also like the getty process which actually monitors a terminal line waiting for a user to login and also we have some special purpose administrative processes as well. Now we see the algorithm for the exit system call. Let us see what all happens. Now the input to this is the return code for the parent process. The kernel first disables the signal handling for the process because it no longer makes any sense to handle the signals. If the exiting process is a process group leader associated with a control terminal then in that case the kernel assumes the user is not doing any useful work and then it sends a hang up signal to all the processes in the process group. So thus if a user types the end of file character that is a control D character in the login shell while some processes associated with the terminal are still alive then the exiting process will send them a hang up signal. The kernel also resets the process group number to 0 for the processes in the process group because it is possible that another process will later get the process ID of the process that has just exited and that it too will be a process group leader and processes that belong to the older process group will not belong to the later process group and kernel then goes through the open file descriptors closing each one internally using the algorithm close and releases the inodes it had accessed for current directory and changed route if it exists via the algorithm I put then the kernel releases all user memory by freeing the appropriate regions with algorithm detach rich and changes the process state to zombie. It saves exit status code and accumulated user and kernel execution time of the process and its descendants in the process table. The kernel also writes an accounting record to a global accounting file containing various runtime statistics like user ID CPU and memory usage and amount of IO for the process. User level programs can later read accounting file to gather various statistics that are useful for performance monitoring and customer billing. And finally the kernel disconnects the process from the process tree by making process one that is in it adopt all its child processes that is the process one now becomes a legal parent of all the live children that the exiting process had created. If any of the children are zombie then the exiting process sends in it a death of child signal so that in it can remove them from the process table. The exiting process sends its parent a death of child signal also in the typical scenario the parent process executes a wait system call to synchronize with the exiting child and the now zombie process does a context switch so that the kernel can schedule another process to execute the kernel never schedules a zombie process to execute. So now the students are expected to think and write the answer to the following question. What are the causes of process termination? So now the students are expected to pause the video and write your answer. Okay so let us see the causes of process termination. The first causes execution completion that is execution may have been completed. The second the parent process requesting for child process termination that could be another cause. Then the third cause trying to use a resource that is not allowed therefore it got terminated. Fourth in case any IO failure may have occurred. Fifth due to the parent process getting terminated the process gets terminated and finally due to some reasons like memory scarcity the process may get terminated. Okay now let us see an example of the exit. A process creates a child process which prints its PID and executes the paused system call suspending itself until it receives a signal. The parent process prints the child's PID and then exits returning the child's PID as its status code. If the exit call were not present the startup routine calls the exit when the process returns from the main. The child process spawned by the parent lives on until it receives a signal even though the parent process is gone. Okay next we will see awaiting process termination. A process can synchronize its execution with termination of a child process by executing the wait system call. Now the following is a syntax for the wait system call PID equal to wait into bracket start address where PID is actually the process ID of the zombie child and start address is the address in the user space of an integer that will contain the exit status code of the child. Now this is the algorithm for wait. The kernel searches for a zombie child of the process and if there are no children returns an error. If it finds a zombie child then it extracts the PID number and the parameter supplied to the child's exit call and returns those values from the system call. An exiting process can thus specify various return codes to give the reason it exited but many programs do not consistently set it in practice. The kernel adds the accumulated time the child process executed in the user and in the kernel mode to the appropriate fields in the parent process U area and finally releases the process table slot formally occupied by the zombie process. Then the slot is now available for a new process and if the processes executing wait has child processes but none of them are zombie then in that case it sleeps at an interruptable priority until the arrival of a signal. The kernel does not contain an explicit wake up call for a process sleeping in wait. Such process only wake up on receiving signals. So for any signal except the death of child the process will react as described. However if the signal is the death of child then the process may respond in a different manner. This is the reference used for the video lecture. Thank you.