Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: UNIX child processes

Re: UNIX child processes

From: <patminnis_at_my-deja.com>
Date: Wed, 02 Feb 2000 14:44:45 GMT
Message-ID: <879fss$f50$1@nnrp1.deja.com>


I am reposting my original message with the new information that the Oracle session in question is not sniped. I did notice that the parent pid is 1 which as I recall is normal for a server process. But this also means that Oracle must be the one that determines when the process will be stopped. SQLNET.EXPIRE_TIME=10 on our system.

Original message follows: (with full test shell script included)

We are running Oracle Applications on a Digital UNIX platform -- but I have duplicated the effect with simple shell script with sqlplus as follows:

Shell script written to call sqlplus with PL/SQL block as in:

   sqlplus system/p0l3s <<EOF
   set pages 1000
   set arraysize 1
   whenever oserror exit failure rollback;    whenever sqlerror exit failure rollback;    declare

     cursor c1_cursor is
       select a.ACTION_SEQUENCE
         from PAY_PAYROLL_ACTIONS a, PAY_PAYROLL_ACTIONS b;
   begin
     for c1_record in c1_cursor loop
       dbms_output.put_line(c1_record.ACTION_SEQUENCE);
     end loop;

   end;
   /
   EOF
   if [ ! $? ]; then; exit; fi

I find the unix pid that corresponds with the sqlplus and I find the shell script

I close my telnet session

Shell script process is gone. sqlplus pid continues running; it is definitely running -- I can watch the CPU% changing up and down.

This seems to be normal behavior on our system. Children continue to run without a parent.

So my question is, why doesn't the child process go away? Is there a way to subvert this behavior? Would I want to?

Oracle Applications DBA's:
This is occurring when we cancel a custom concurrent request. These programs are written as host shell scripts which run sqlplus, perhaps multiple times in the same shell script.

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Wed Feb 02 2000 - 08:44:45 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US