Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!hp4nl!star.cs.vu.nl!maart
From: maart@cs.vu.nl (Maarten Litmaath)
Newsgroups: comp.unix.questions
Subject: Re: signal problems on BSD
Message-ID: <5913@star.cs.vu.nl>
Date: 6 Mar 90 16:56:34 GMT
References: <34853@cci632.UUCP> <1990Mar6.070333.29327@athena.mit.edu>
Sender: news@cs.vu.nl
Reply-To: maart@cs.vu.nl (Maarten Litmaath)
Organization: VU Informatika, Amsterdam, the Netherlands
Lines: 52

In article <1990Mar6.070333.29327@athena.mit.edu>,
	jik@athena.mit.edu (Jonathan I. Kamens) writes:
)...  While sh
)automatically sends a HUP signal to all its children when you log out
)(actually, I'm not sure the shell does this actively; it's might be a
)side-effect of the way and process groups et al work in BSD), this

It's always been the kernel.  Quoting from termio(4) on SunOS 4.0.3c:

  Modem Disconnect
     If a modem disconnect is detected, and the  CLOCAL  flag  is
     not set in the c_cflag field, a SIGHUP signal is sent to all
     processes in the distinguished process group associated with
     this  terminal.   Unless  other arrangements have been made,
     this signal terminates the processes.  If SIGHUP is  ignored
     or caught, any subsequent read() returns with an end-of-file
     indication until the terminal  is  closed.   Thus,  programs
     that  read a terminal and test for end-of-file can terminate
     appropriately after a disconnect.   Any  subsequent  write()
     will  return  -1  and set errno to EIO until the terminal is
     closed.

)doesn't happen in csh.  Therefore, the reason your process is not
)getting the signal is because the signal is never sent.

...because csh puts each job into its own process group and a the group of a
background job never equals the tty process group (by definition!).

)  Here at Project Athena, we have a hack in our /bin/login which makes
)it possible to do what you want, although I don't know how universal
)this is (it isn't in the vanilla 4.3-tahoe sources, which means it isn't
)a standard 4.3bsd thing).  After the child process (i.e. the login
)shell) of /bin/login exits, /bin/login does "killpg(child, SIGHUP)",
)where "child" is the process group of the child.

Why don't you let the kernel or init(8) do the killpg()?  Now you have an
extra process hanging around, doing nothing but wait()ing.

)  Then, any process that wants to get a HUP signal when it logs out,
)after being placed into the background upon start-up, simply does
)"setpgrp(0, getpgrp(getppid()))".  In other words, "Make my process
)group the same as the process group of my parent."  This overrides the
)default csh behavior of creating a new process group for each child
)process it runs.  [...]

I assume you wrote a utility `hup' (the opposite of nohup(1)) too:

	a) to do this setpgrp() for you (!)
	b) to catch the keyboard signals (!!)
--
  "Belfast: a sentimental journey to the Dark Ages - Crusades & Witchburning
  - Europe's Lebanon - Book Now!" | maart@cs.vu.nl,  uunet!mcsun!botter!maart