"Mike A. Harris" wrote:
>
> On Sat, 26 Feb 2000, Jos Visser wrote:
>
> >Running the risk to be deemed an irresponsible featurist I submit the
> >following:
> >
> >SHORT:
> >-----
> >
> >Let's extend the kernel with a /proc/nzombies feature that tells the
> >current number of zombies. This is handy for system and network
> >monitoring purposes. I did some homework and it is a quite trivial
> >extension to exit.c.
> [SNIP]
>
> Instead of producing such a patch, that is really duplicating
> existing information for no real good reason - why not actually
> *FIX* the applications that are zombifying? Any app I've found
> that zombies all the time, it is usually a one liner patch that
> fixes it. Of course that assumes that it is open source we're
> talking about. If it is closed source or proprietary however,
> then you should pound on your vendor's door and tell them their
> application is broken and you want your money back.
Before I can fix the problem, or pound on the vendor, I have to be aware
that the problem exists. I need automated system monitoring for that,
and the system monitors must have a quick and efficient way to get at
the information.
Once I know the problem exists, and before the vendor has solved it (in
which they are not always as responsive as one would like), I need to be
able to implement an automated temporary fix (e.g. bouncing the parent
process). The automated operations framework needs to recognise that the
problem is occurring again, and therefore needs to get at the
information.
Obviously the problem are the closed source applications. It is usually
not possible to dump an application that has been selected for
functional/business purposes because of a minor technical
problem/nuisance.
++Jos
-- All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.- 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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:16 EST