Process Concept – III – Process Termination

PROCESS TERMINATION

Continuing our discussion from the previous post, we discuss the topic of process termination here. This post discusses the normal sequence of events for process termination, along with some interesting types of processes which include zombie process, orphans and daemons.

How does a process terminate?

Process termination occurs in the following manner under normal circumstances:

  • After a process has finished executing its final statement, it asks the OS to delete it by using the exit() system call.
  • At this point, the process may return a status value (typically an integer) to its parent process. This is done using the wait() system call.
  • Also, all the resources of the process – including physical and virtual memory, open files, I/O buffers, are de-allocated by the OS.

Note that the above case discusses normal termination, which occurs when the process has finished executing.

Termination can occur in other circumstances as well.

  • Causing termination of another process via appropriate system call
    • e.g. TerminateProcess() in Windows OS
    • Such a system call can be invoked only by the parent process. This is done to prevent users from arbitrarily killing each other’s jobs.

When does a parent process kill a child process?

A parent may kill its child due to a variety of reasons.

  • Child has exceeded its usage of some resources which had been allocated to it.
    • Parent needs to know the identity of the process in order to kill it. This is the reason why identity of newly created process is passed to the parent (to facilitate identification)
  • The task assigned to the child is no longer needed.
  • The parent is exiting, and the OS does not allow a child to continue if the parent terminates.
    • The phenomena of terminating the children, when a parent has terminated (either normally or abnormally), is known as Cascading Termination.
    • Cascading Termination is normally initiated by the OS.

ZOMBIE PROCESS

Let us first summarize the general process of execution and termination of a process.

  • After a process has finished executing, it can exit in normal circumstances by issuing an exit system call
    • either directly → exit(1), i.e. exit with status 1
    • or indirectly → by a return statement in main
  • A parent may wait for the termination of its child by using the wait() system call.

  • The parameter status is passed to the wait system call which allows the parent to obtain the exit status of the child.
  • wait() also returns the pid of the terminated child so that the parent can identify which of its children got terminated.

To understand about a zombie process, let us first get acquainted with the term Process table.

Process table 

  • data structure maintained by the OS
  • used to facilitate context switching and process scheduling
  • entry in table known as → Context block
  • Context block contains information about a process such as
    • Process name
    • Process state
    • Priority information
    • Registers and Semaphores
    • Entry to Page tables (if the OS supports paging)
  • The index of process table entry is usually associated with a process to identify it → also known as process id

Now , coming back to process termination. 

  • Process terminated → Deallocate resources [ done by the OS]
  • However, entry in process table must remain, until the parent calls wait()
  • Why ? → Process Table maintains the exit status of each process, which can be known only via the wait() system call.
  • A process that has terminated, but whose parent has still not invoked wait(), is known as a zombie process.
    • Zombie process → died but not reaped
    • Unlike normal processes, kill command has no effect on a zombie process (hence the origin of using the word zombie :p)
    • While terminating, all processes transit to this state, though briefly
    • Once parent calls wait(), pid of zombie process and its entry in process table are released.

Another interesting situation can also occur.

  • A parent that did not invoke wait() and instead terminated, leaves its child processes as orphans.
  • Therefore, an orphan process is a process that is still executing, but its parent has died. Processes can become orphans
    • unintentionally, e.g. when the parent process crashes or terminates.
    • intentionally, when it is required to detach a process from the user’s session and leave it running in the background, to allow a long-running job to complete without further user attention.
    • However, this is different from daemon , which is a process that runs as a background process, rather than being in control of an interactive user.
      • creation of daemon
        •  fork a child
        • exit immediately, causing init to adopt the child
      • daemon processes usually end with a d, e.g. syslogd, httpd, and so on.
  • In UNIX, init process (pid = 1) is assigned the parent of orphan processes.
  • The init process periodically invokes wait() →  thereby allowing the exit status of any orphaned process to be collected and releasing the orphan’s process identifier and process-table entry.

In response to the comments below, the differences between Process table and Process Control Block are

Process Control Block (PCB)Process Table
A Process Control Block is a data structure in the operating system kernel which contains all the relevant information needed to manage a particular process.A Process Table is a data structure maintained by the Operating system to facilitate Process Scheduling and context switching. It is an array of Process Control Blocks (PCBs)
Each Process has its own PCB.Each process appears as an entry in the PCB, indexed by the process id (pid).

Difference between Orphan Process and Daemon Process

 

Orphan Process

Daemon Process

1

An orphan process is a process that is still executing, but its parent has died (terminated)

A Daemon Process is a process that runs as a background process, rather than being in control of an interactive user.

2

An orphan process can be formed intentionally or unintentionally. A process becomes orphan unintentionally if the parent crashes or terminates. On the other hand, when it is required to detach a process from the user’s session and leave it running in the background, to allow a long-running job to complete without further user attention, intentional orphans are created.

A daemon is created by forking a child and exiting immediately, causing the init process to adopt the child. This is same as an intentional orphan. In UNIX, the intentional orphans are typically called daemon processes.

In the next post, we will continue this discussion on Process Concepts with Inter-process communication.
Until then, keep reading and sharing 🙂

 Sources: 1, 2