steinar@fdmetd.uucp (Steinar Overbeck Cook) (10/20/89)
In the Installation and Users guide for Oracle V5 it says that ORACLE uses the signals SIGINT, SIGPIPE and SIGTERM to send signals from the shadow process to the user process. The manual states that SIGTERM is "Used by the Pipe Driver to resynchronize communication between the user and ORACLE after an error or interrupt." This is fine, but *what* sort of errors makes the shadow process send SIGTERM. I have a daemon which is connected to an ORACLE database, but if I close all open files at startup (Which all good daemons should do), after a while I get SIGTERM from the shadow process when I do some fork/execs in my server. Does anyone have a list of when ORACLE's shadow process will signal SIGTERM ? Any help would be greatly appreciated. -- Steinar Overbeck Cook, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY Phone : +47 2 52 80 80 Fax : +47 2 52 85 10 E-mail : ...!mcvax!ndosl!fdmetd!steinar or steinar@fdmetd.uucp <The opinions expressed, if any, do not represent Fellesdata a.s>
cgd@pyrps5 (Greg Doherty) (10/22/89)
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
steinar@fdmetd.uucp (Steinar Overbeck Cook) (10/27/89)
In article <88461@pyramid.pyramid.com> cgd@pyrps5.pyramid.com (Greg Doherty) writes: [.... text deleted. ....] > >It seems to me that your problem may be in closing all open file descriptors >in your server. > No, I close all files, *before* I connect to the Oracle database :-). The following piece of pseudo code shows in brief what happens: main(....) . . pid = fork(); /* Don't want to be group leader */ if (pid != 0) exit(0); /* Parent terminates */ setpgrp(); /* Loose controlling terminal & change process group */ pid = fork(); if (pid != 0) /* Become non-pgrp-leader */ exit(0); /* First child */ for (fd=0; fd < _NFILE; fd++) /* Close all open files */ close(fd); chdir("/"); /* Move current directory of mounted filesystem */ umask(0); /* clear any inherited file mode creation mask */ CONNECT TO ORACLE; for(;;){ get_request_from_client(); when a certain request comes along{ fork(); exec("delta ......."); ...... <======HERE COMES SIGTERM !!! } } Does anybody have a good suggestion on why I get SIGTERM in cases like this ? >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.. ^ What does this mean ? ------------------ -- Steinar Overbeck Cook, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY Phone : +47 2 52 80 80 Fax : +47 2 52 85 10 E-mail : ...!mcvax!ndosl!fdmetd!steinar or steinar@fdmetd.uucp <The opinions expressed, if any, do not represent Fellesdata a.s>
barr@frog.UUCP (Chris Barr) (11/02/89)
In article <744@fdmetd.uucp> steinar@fdmetd.UUCP (Steinar Overbeck Cook, Fellesdata a.s) writes: >>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.. > ^ >What does this mean ? ------------------ Out-Of-Band Break is an abort message to the back end (2nd of 2 tasks) which jumps to the front of the message queue rather than waiting (In-Band) for work in progress to complete. It causes any work in progress to stop. Not all 2-task implementations (ports) of Oracle support OOB Break. Cleanup is harder.