Messages in this thread | | | From | Werner Almesberger <> | Subject | Re: /proc/nzombies | Date | Fri, 3 Mar 2000 15:29:26 +0100 (MET) |
| |
Riley Williams wrote: > More realistically: > > maxsize = get_process_count() + 100;
This is probably better, yes.
> size = get_process_data(buffer);
get_process_data(3), not get_process_data(2), I hope :-) In any case, you probably want to preserve the ability to read the table in multiple steps, possibly sacrificing any atomicity assurances a single operation may (or may not - they're expensive) give.
> If so, then an obvious solution would be to move zombies out of > the process table into a separate linked list (or perhaps into > the /proc/nzombies file) and thus free up the process slots they > used to occupy.
Doable, but I'm not sure about its usefulness: zombies should be the rare exception, so under normal circumstances, they don't load your system in any significant way. Now if you have an application that sometimes goes berserk and spawns lots of zombies, you probably want to kill the application anyway.
In the case where you have an application that constantly leaks zombies, compressing zombie state is only postponing the problem. What you want to do there is either to force it to reap its zombie-children, or to kill the zombies entirely (after all, their parent doesn't seem to be interested).
It may be feasible to sneak a call to waitpid(...,NULL,WNOHANG) into the process space of the parent using ptrace. This would nicely solve the problem of broken but unfixable applications without adding extra code to the kernel.
For killing zombies, you may want to consider implementing a SIGZOMBIE, which would be equivalent to a SIGKILL, except that it's only delivered to zombies. This may, however, open a discussion similar to the one on /proc/nzombies ;-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |