Re: SQL*Net leaving defunct processes on server

From: Chris Thompson <cet1_at_cus.cam.ac.uk>
Date: 3 Sep 1994 15:47:36 GMT
Message-ID: <34a5qo$qdf_at_lyra.csx.cam.ac.uk>


In article <2752_at_intermec.UUCP>, awilson_at_intermec.com (Adrian Wilson) writes:
>
> Re: SQL*Net leaving defunct processes on server
> tonyh_at_muppet.bt.co.uk (Anthony Hudson ) writes:
>
> >Our Oracle 7 server crashed this morning with the message (proc: table is full)
> >There were 200 odd defunct processes owned by oracle.
> >It would appear that every connection/disconnection from the PC leaves one defunct
> >process.
> >Since kill does not work on a defunct process.
> >Can anyone tell me how to stop this happening again (other than rebooting the
> >server daily).
> >
> >
> >I am running Oracle Version 7.0.16.6.0 and orasrv Version 1.2.7.7.1 on a Sparc 10
> >with SunOS Release 4.1.3_U1 (GENERIC) #2.
> >Oracle Forms 4 is being run on half a dozen PC's.
>
>You would find in the version of SQL*Net that you are running, that every time
>a user logs out the process does not kill itself. And the processes keep
>accumulating and filling the UNIX process table.
>
>This is a know bug. Have Oracle send you a patch and you
>should not have to reboot your pc daily.

Specifically, the version of orasrv shipped on the Oracle 7.0.16.4 for SunOS 4.1.3 CDROM has been compiled with mangled SIGCHILD handling. (Superficial analysis suggests that options more suitable for Solaris 2 were used when making it.) The result is that *every* shadow process (one per login/connect) ends up as a zombie. (You don't need to be using SQL*Net to have the problem.)

The quick circumvention is to use the orasrv binary from the 7.0.15 CDROM, which didn't have this bug. Moreover, both orasrv's are identified as 1.2.7.7.1 so that if you have used the installer to upgrade from 7.0.15 to 7.0.16 then it will not have replaced the orasrv binary and you won't have the problem!

Chris Thompson
Cambridge University Computing Service
Internet: cet1_at_ucs.cam.ac.uk
JANET: cet1_at_uk.ac.cam.ucs Received on Sat Sep 03 1994 - 17:47:36 CEST

Original text of this message