lkml.org 
[lkml]   [2000]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: /proc/nzombies
Date
"A month of sundays ago Ricky Beam wrote:"
> On Sat, 26 Feb 2000, Peter T. Breuer wrote:
> >"A month of sundays ago Jos Visser wrote:"
> >> Let's extend the kernel with a /proc/nzombies feature that tells the
> >> current number of zombies. This is handy for system and network
> >It's not at all daft. Why not put them in /proc/lost+found/ instead?
> <humor>
> Would I have to run mklost+found on /proc? Would it be a 12k directory
> like every other lost+found?

I think it might have to be :-). Well, how many zombies can _you_ spawn?

> And, would one have to run fsck.proc to get the zombies in there?

You mean "out of there". Well, yes, it might well ask if you want init
to vamoosh them, or whether you'd like a core dump instead.

> Might I suggest a /proc/0/... tree of process information? (task[0] is
> the kernel after all.) It would help reduce the clutter in /proc. It

Not bad (isn't it the task that isn't?). But using the inodes as
numbers and the names as names might make more sense! /proc/kernel,
/proc/init, etc... (and there is nothing wrong with /proc/lost+found,
except that it had better have a crazy inode number, as it can't ever
collect itself).

What does this clutter matter, btw? I think the valid point you really
have concerns the chroot'ed root who can mount /proc and therefore get
at all processes .. as though he couldn't already mount the disk
partitions and do enough damage (and telnet to his own copy of telnetd
...).


Peter

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.044 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site