mjb@acd4.UUCP ( Mike Bryan ) (11/28/89)
Another reader at this site says he remembers seeing a set of articles about 3 to 4 weeks ago dealing with problems in ORACLE 6.0 regarding the Two-Task Pipe Driver. We are having serious problems, and this description sounds like the same problem we are having (the ORACLE shadow processes seem to unexpectedly die, and the parent gets a signal 13 or 14). If anyone remembers these articles, or has them archived somewhere, I'd appreciate any information you can give me. (Unfortunately, I did not start reading comp.databases until a week ago, and the other reader did not realize the significance of those articles at the time.) Please respond via E-mail if possible. Thanks in advance... -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb INTERNET: mjb%acd4@uunet.uu.net "Agony is born of desire; that's what you get for wanting." --- Moev
cgd@pyrps5 (Greg Doherty) (11/28/89)
Here's some mail I tried to send to the person who brought up the two-task SIGTERM problem, but it's been bouncing every time I send it. The whole discussion started with folks trying to write Oracle applications as daemons, eg: with stdin, stdout, and stderr closed. Another tidbit for sig 14 (SIGALRM): don't arm an alarm before logging in to Oracle. Oracle will supposedly reset the signal handler, which, when your alarm goes off, will do a longjmp() out of an uninitialized jmpbuf. Set your alarm()'s after logging in, or disarm them, with alarm(0), before logging in.. cgd --- Hi Steinar, I've been looking into this issue some more, both on your behalf, and on behalf of a Pyramid/Oracle customer who is having similar problems. My investigations have been under V6 of Oracle, but the Pipe driver has not changed that much so the following may apply to you under V5. If my suggestion helps, you might post a follow-up article to the net.. First, there is a generic bug in the Pipe driver that I have fixed for V6.0.27 of Oracle (I spend most of my time at Oracle). If stdin, stdout, or stderr are closed when you connect to Oracle, then the Pipe driver will screw up the closing of the unused sides of the pipes. In your program below, I suggest opening 0,1,2 to /dev/null before the CONNECT and then closing them afterwards as a workaround. Second, the Pipe driver sets the CLOSE-ON-EXEC flag on the Oracle pipes so you can't make a child process inherit the Oracle Pipe connections.. so if "delta" below in the exec() call tries to do any Oracle work, it won't work correctly at all.. Greg Doherty Oracle Project Leader Pyramid Technology ----- > > 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); /* make sure file descriptors 0, 1, & 2 are occupied */ open("/dev/null",0); open("/dev/null",0); open("/dev/null",0); > chdir("/"); /* Move current directory of mounted filesystem */ > umask(0); /* clear any inherited file mode creation mask */ > > CONNECT TO ORACLE; /* now close those useless file descriptors */ close(0); close(1); close(2); > for(;;){ > get_request_from_client(); > when a certain request comes along{ > fork(); > exec("delta ......."); delta must not attempt to do any Oracle related work, unless it logs itself back in by executing another EXEC SQL CONNECT... > ...... <======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 ? ------------------ O-O-B means "Out of Band Break" which is the SIGTERM mechanism used which is not usually the default.