[Info-vax] Orphaned processes on OpenVMS

[Bob Koehler]

In article <7f51d553-f496-4689-bc07-444c8a33aa5f at 34g2000pru.googlegroups.com>, Wendell <wendellxe at yahoo.com> writes:
> One of my biggest aggravations with *nix is the persistence of
> orphaned processes. Say an app hangs. I log in to another virtual
> terminal and "kill" it. That leaves various, no longer needed
> processes still running, and the only way to really clean up is reboot
> the system. At the worst, these stragglers can interfere with
> restarting the app I had to kill.
> 
> I've heard it said that OpenVMS doesn't have this problem at all. How
> does it prevent orphans or at least allow cleanup without rebooting?

   In VMS all subprocesses depend on thier parent processes.  If you
   kill the parent, VMS walks the job's process tree and first kills
   the lowest children, not completing the death of the process you're
   killing until the lower parts of the tree have gone.  When a higher
   up process is waiting for it's children to die, it goes into a
   special scheduling state.  Normally you don't see processes in
   that state because it all happens so fast.  There cannot be any orphans.

   In VMS, a process can be detached, meaning it has no parent.  A
   new detached process defines a new job, which consists of a detached
   process and all it's subprocesses.  This is relavent to things like
   the job logical name table.

   In UNIX, all processes except init have a parent.  There is no
   concept of a detached process.  If you kill a process all subprocesses 
   are inherited by the next parent up the tree.  You can't kill init.
   The closest thing to a job tree is that most shells will tell you
   all the children below the shell process, but the shell process
   itself has a parent.

   You can walk the process tree yourself in UNIX, finding the children
   of a process and killing them yourself, before you kill the process
   you're aiming at.

   This is simply a difference in the design and implementation of the
   OS kernel.