gnomerc=Zombie

Taavi Burns jaaaarel-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Mon Nov 15 00:44:00 UTC 2004


On Sat, 13 Nov 2004 14:52:38 -0500 (EST), Robert Brockway
<rbrockway-wgAaPJgzrDxH4x6Dk/4f9A at public.gmane.org> wrote:
> On Fri, 12 Nov 2004, Taavi Burns wrote:
> 
> > But it IS consuming resources: an entry in the process table.  I'm quite
> > sure that I've heard of machines which required a reboot because the
> > process table became full (the process table size on UNIX has
> > historically been a boot- or compile-time parameter).  I don't know if
> > modern Linux kernels have improved on this or not, but last time I
> > checked 32-bit Linux still only used 16-bit PIDs, meaning that when you
> > reach around 65534 zombies (since you need init, and I don't think PID 0
> 
> The PID is a signed 32-bit value so it wraps at 32768.

I think you mean signed SIXETEEN-bit value.  That may be the case.
Now that I look, I don't actually have any processes over ~31k... :)

> Up until sometime in 2.3 the process table was much smaller than this.
> The #define NR_TASKS was set to 512 by default (128 in really old
> kernels). Filling the process table with zombies could indeed ruin an
> admins day.
> 
> Things are better now.  cat /proc/sys/kernel/threads-max to see the
> maximum number of threads the system will allow.  This number can be
> changed on the fly.  I guess there is still some upper limit.

Threads are not processes.  Threads exist within processes.  Now, a
program may opt to use threads instead of processes, but this has nothing
to do with actual process zombies taking up process table entries.

> Remember exec can come to the rescue too - it replaces one process with
> another in the process table rather than creating a new process table
> entry (as normally happens when you fork).  Quite a few admins have exec'd
> a kill to fix a running system.

The trick is having a process around in the first place, and you have to know
what processes to kill (i.e. the parent of the zombies).

-- 
taa
/*eof*/
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list