Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!sun-barr!decwrl!nsc!pyramid!cgd
From: cgd@pyrps5 (Greg Doherty)
Newsgroups: comp.databases
Subject: Re: SIGTERM, SIGINT from ORACLE's shadow process.
Keywords: SIGTERM SIGINT ORACLE daemons
Message-ID: <88461@pyramid.pyramid.com>
Date: 21 Oct 89 18:31:55 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: cgd@pyrps5.pyramid.com (Greg Doherty)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 24

SIGTERM is used by the Oracle Pipe two-task driver to resynchronize
if and only if you have explicitly specified to the Pipe
driver that you want to use "OUT-OF-BAND BREAK", which, on most Oracle
ports is *not* the default.

It seems to me that your problem may be in closing all open file descriptors
in your server.  If you do this after logging in to Oracle via EXEC SQL
CONNECT, you would efectively close the pipes over which your server
communicates to its Oracle shadow process, thus forcing a SQL*Net 3113
"end-of-file on communication channel" error.   This, however, is so obvious
that perhaps the problems you are experiencing are more subtle and
mysterious.

Maybe you are failing to close all open file descriptors in the children
of the server you create when they start up.  Without the close()'s you
might have more than one frontend Oracle client trying to talk to a single
Oracle shadow..

In order to get SIGTERM flying around between Oracle clients and servers
you would have to explicitly set the environment variable "TWO_TASK" to
"P:,O", so you can probably eliminate SIGTERM to your server as a cause
for termination, unless you're using O-O-B BREAK..

cgd