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