From owner-freebsd-questions  Sun Jul 28 03:25:47 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id DAA13993
          for questions-outgoing; Sun, 28 Jul 1996 03:25:47 -0700 (PDT)
Received: from galisant.demon.co.uk (galisant.demon.co.uk [158.152.9.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA13984
          for <freebsd-questions@FreeBSD.org>; Sun, 28 Jul 1996 03:25:43 -0700 (PDT)
Path: galisant.demon.co.uk!gordon
From: gordon@galisant.demon.co.uk (Gordon Beck)
Subject: killing child processes
References: <199607251350.NAA00377@CoDe.CoDe.hu> <31FA4AE3.41C67EA6@tir.com>
To: freebsd-questions@FreeBSD.org
Message-ID: <838578160snx@galisant.demon.co.uk>
X-Mailer: cppnews $Revision: 1.41 $
Date: Sun, 28 Jul 96 11:22:40  GMT
Organization: Galisant Ltd
Lines: 27
Sender: owner-questions@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk


I have a monitor daemon which forks and runs an application.


If the application dies then the daemon get to know about it.
However, if the daemon dies or is killed, then the child continues to run.

I had expected the child to get a SIGHUP, which it is not blocking.
However, I think that SIGHUP is only generated if the daemon is
a process group leader and had a control terminal whose TGRP matched
the process group (?).


If a daemon process issues setpgrp then it can on longer acquire a control
terminal(?), which is cache 22.


Anyone have clues/pointers/source code for a general or specific solution
to this problem


gordon


Gordon Beck     | gordon@galisant.demon.co.uk   |
                |                               |
Durham UK       |                               |The Questing Beast