Browse Prior Art Database

Monitoring Abnormal Process Termination in Multi-Process Systems

IP.com Disclosure Number: IPCOM000115988D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 97K

Publishing Venue

IBM

Related People

Butler, ND: AUTHOR [+4]

Abstract

"Abnormal process termination" occurs when a program exits unexpectedly. There are may reasons for this occurring, and when this happens some system cleanup, or error reporting may be required. This requires the system to "know" or "recognize" when a certain process terminates abnormally.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Monitoring Abnormal Process Termination in Multi-Process Systems

      "Abnormal process termination" occurs when a program exits
unexpectedly.  There are may reasons for this occurring, and when
this happens some system cleanup, or error reporting may be required.
This requires the system to "know" or "recognize" when a certain
process terminates abnormally.

      In a traditional UNIX* process structure where a "parent"
process controls one or more "child" processes, the parent can
monitor the activities of its children using signals and other
Application Programming Interface (API) functions.  But this approach
requires that each "parent" process on the system implements a
similar set of functions to handle its child termination.  Also, a
child can "detach" itself from its parent process, which removes
control of the child process from the parent.  Such "detached"
processes may also require some cleanup/error reporting when they
abnormally terminate.  The existing API functions cannot achieve this
in the same manner.  This method is also inappropriate if a system
wants one process to monitor several unrelated processes and perform
some action when one or more of them terminate abnormally, such as
collecting diagnostic information.   Such a centralized termination
reporting process cannot gather the necessary information.

      Another approach is to regularly poll the system asking "is
this process alive?"  This method introduces performance overhead and
can only report the fact that a process has "died" at intervals equal
to the regular poll.   Thus, the smaller the interval, the more
system overhead required.

      The solution described here is based on the fact that whenever
a process terminates abnormally, the operating system, as part of the
automatic cleanup for the dying process, closes all file descriptors
which are open at the time of process termination.

      This may happen, for example, when a process with open files is
halted by the operating system for using an invalid memory address.

      Using this functionality (which appears on many operating
systems, such as AIX*/UNIX/OS2*... etc.) a kernel extension can be
built which acts as a monitor for these dead processes.

      Each process which wants to report its termination to someone
else opens a file-descriptor with the monitor.  Once open, the
process passes information about itself to the monitor.  This
information would enable other processes to request notification of
termination of certain processes, or types of processes.  The m...