Proper exit handling

[Root Boy Jim]

? Posted-Date:  27 Mar 89 08:43 EST
? Date:  Mon, 27 Mar 89 08:42 EST
? From: Kemp at DOCKMASTER.DCA.MIL

?    Does anyone know of a bulletproof method of installing an exit
? handling routine that is guaranteed to be called when a process
? terminates?

[discussion of trapping signals deleted]

?    This works fine under normal circumstances, but if something unusual
? happens which kills the process (bus error, arithmetic exception, or any
? of a million other things), the terminal will be left in hosed mode.  I
? could trap the 20 signals that cause a process to die, but that is a
? gross and ugly hack, and besides what about SIGSTOP and SIGKILL, which
? cannot be caught?

Well as you said, there is nothing you can do about SIGSTOP or SIGKILL,
but I can map your list of 20 signals down to one (perhaps 2): SIGCHLD.
Save the original terminal state, fork a child, wait for it, when it
dies, reset the terminal state. Things can get more complicated if the
program is expected to be suspended with ^Z. In that case, the parent
should probably ignore SIGTSTP and let the child muck with the settings.

?    Thanks,
?     Dave Kemp (Kemp at dockmaster.arpa)

? p.s.  Can anyone tell me where in TFM to find documentation on SIGTERM
? (the software termination signal)?  It would be nice if this were sent
? by exit() TO the terminating process, but I assume that it is just
? another of the signals that causes the process to terminate.  SIGNAL(3)
? doesn't say anything about it except to list its value.

It's just another signal you can send, with the conventional meaning
of "Nothing's wrong, but we don't need your services anymore. Don't
go away mad, just go away." A good example can be found in init(8).

	Root Boy Jim is what I am
	Are you what you are or what?