System V and the Hangup Signal

[rml at hpfcdc.UUCP]

One possibility that comes to mind is the following scenario:

	- "hardware hangup" occurs, sending SIGHUP to process group

	- process group leader (possibly login shell) receives
	  SIGHUP and dies

	- exit processing sends SIGHUP to process group again

	- second SIGHUP arrives while signal is set to SIG_DFL
	  (due to receipt of the first SIGHUP).

If this is the case, there's not much you can do on V.2.

Another (more remote) possibility that occurred to me is that a break is
being detected prior to the hangup.  In that case you should be able to
ignore or catch SIGINT.

You may be able to debug the problem by spawning the application from an
extra process which ignores SIGHUP, waits for its child(ren) and looks
at the exit status.  You could also find the exit status in the process
accounting data (see acct(4)).  In my first scenario the exit status
will be 1 (SIGHUP); in the second 2 (SIGINT).

			Bob Lenk
			{hplabs, ihnp4}!hpfcla!rml