From owner-freebsd-questions  Mon Jul 29 08:12:20 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id IAA03523
          for questions-outgoing; Mon, 29 Jul 1996 08:12:20 -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 IAA03501
          for <questions@freebsd.org>; Mon, 29 Jul 1996 08:12:13 -0700 (PDT)
Path: galisant.demon.co.uk!gordon
From: gordon@galisant.demon.co.uk (Gordon Beck)
Subject: Re: killing child processes
References: <199607282236.WAA03556@jraynard.demon.co.uk>
To: fqueries@jraynard.demon.co.uk
Cc: questions@freebsd.org
Message-ID: <838681846snx@galisant.demon.co.uk>
X-Mailer: cppnews $Revision: 1.41 $
Date: Mon, 29 Jul 96 16:10:46  GMT
Organization: Galisant Ltd
Lines: 56
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In article <199607282236.WAA03556@jraynard.demon.co.uk> you write:
>>
>>
>> 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.
>
>Yep, this is normal behaviour - the child becomes a child of init
>instead of its original parent.
>
>> 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.
>
>>From what I understand of it, this sounds like you're expecting the
>SVR3 behaviour, where a "process group" corresponds loosely to all
>the commands started in a login session. FreeBSD follows POSIX, where
>a "process group" corresponds to a job and the login session is
>referred to as a "session" (the difference is necessary to add
>support for BSD-style job control).
>
>

Thanks for your response. I think I nearly have what I was looking for.


setsid() (and probably setpgrp()) cannot be issued from a process which
is already a group leader, I needed to fork once and then become a new session.

Allocating the tty/pty pair was OK, and provided the child did not close the
slave side, it got SIGHUP when the parent died. In fact any child which
had not closed the slave got SIGHUP.

The applications that I want to monitor are probably not tidy enough to close
all of the open fids.

I think the only issue is that I have a dummy tty/pty pair which I are never
used. I was also unable to chown the /dev/ttyXX, which is what xterm et.al. do.
I would have to be effective root. Probably does not matter though.


thanks


gordon

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