Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: defunct processes after patch application on Compaq Tru64 Unix

Re: defunct processes after patch application on Compaq Tru64 Unix

From: Stephane Faroult <>
Date: Mon, 26 May 2003 11:51:50 -0800
Message-ID: <>

> After Applying patch Kit "4" of Compaq Tru64 Unix 5.1A , about 200 concurrent defunct PIDs are spawning during a peak concurrent user load of 800 concurrent application users .
> "defunct" process is generated :-
> 1) when doing an ordinary telnet unix login to the machine
> 2) when doing sqlplus <user>/passwd@<connect string> to the database server
> NOTE - NO defunct process is generated when doing direct sqlplus call to database
> 3) when doing application login which spawns a database connecttion thru SQL*Net
> NOTE - The defunct PID Values belonging to a unix user keep Changing . Seemingly NEW defunct processes keep getting spawned as old ones die off
> This is causing a severe Application performance degradation on production even though there is plenty of FREE CPU & memory available
> NOTE -
> 1) Before application of patch kit "4" , FEWER defunct processes ( 50 at max. ) used to exist
> at any point in time
> 2) Each application user spawns approx 4 unix processes while working with the application
> 3) Network thruput is OK between Application & Database Server
> Qs. Is spawning of defunct processes during unix login normal ?
> Qs. anybody has applied Patch kit "4" on Tru64 Unix ?
> Qs. Any ideas how this issue may be approached ?
> Thanks


   I have no direct experience of this patch but technically a defunct (zombie) process is a process the parent process of which has died unexpectedly. Normally, when a process begets another process, it is expected to wait for a SIGCHLD signal when the child process exits. If it crashes before the child process finishes, the child process cannot die properly and continues to haunt the living. Since your problem is with SQL*Net connections, the answer to your problem is probably to be searched in the direction of tnslsnr, which normally forks the shadow processes. The listener log may provide clues. And a possible workaround (I would certainly try it) could be MTS.  

HTH, Stephane Faroult
Oriole Software

Please see the official ORACLE-L FAQ:
Author: Stephane Faroult

Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message
to: (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Mon May 26 2003 - 14:51:50 CDT

Original text of this message