Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!ucsd!ucbvax!hplabs!pyramid!cgd
From: cgd@pyrps5 (Greg Doherty)
Newsgroups: comp.databases
Subject: Re: ORACLE 6.0 Two-Task Problems
Message-ID: <92688@pyramid.pyramid.com>
Date: 28 Nov 89 01:30:25 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: cgd@pyrps5.pyramid.com (Greg Doherty)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 101


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.


Brought to you by Super Global Mega Corp .com