[request-sponsor] Requesting sponsor for Bug ID 6518130
Sorry for not catching the duplication, Chad. I'll remove Danny's request. Thanks. Bonnie Chad Mynhier wrote: > On Mon, Apr 28, 2008 at 6:54 AM, danny webster > wrote: >> Hi - i'd like to work on the following bug. >> >> Bug ID: 6518130 >> Synopsis: pfiles(1) should list the processes listening on each socket >> Reported: SunOS 5.10 >> > > Hi, Dan, > > I'm curious how you propose to solve this problem, as I've also > requested a sponsor for this. (You can check this page to see if a > bug already has a sponsor request: > http://opensolaris.org/os/bug_reports/request_sponsor/. I'm more than > happy to withdraw my request if you want this, though.) > > You also might want to check out an earlier thread on this > (http://www.opensolaris.org/jive/thread.jspa?messageID=159896𧂘), > specifically Mike Shapiro's comments on this: > >> I'm glad to see this: it's long overdue. The major issue I have though is >> one of implementation: namely, it's way way too heavyweight to use the >> global /proc hammer for this. This really needs to be implemented as >> a kernel service that queries sockfs data structures or whatever >> such that it is just a system call and a hash lookup, and not >> globally stopping and starting every process. The problem with the /proc >> approach is that it means that if you were to have a bunch of junior >> admins run this in production a few times while learning the arguments >> and trying to poke around at some problem, they could literally kill >> performance of the box. Pgrab is *very* heavyweight: you're stopping >> *every* thread of *every process*, kicking it off CPU, making it run >> system calls, etc. This is fine for debugging one bad thing, but >> it's like dropping an atomic bomb on a fully utilized busy machine. > > > Chad Mynhier > ___ > request-sponsor mailing list > request-sponsor at opensolaris.org
[request-sponsor] Requesting sponsor for Bug ID 6518130
Hey Chad, > Hi, Dan, > > I'm curious how you propose to solve this problem, as I've also > requested a sponsor for this. (You can check this page to see if a > bug already has a sponsor request: > http://opensolaris.org/os/bug_reports/request_sponsor/. I'm more than > happy to withdraw my request if you want this, though.) I hadn't seen that this particular bug had an RE assigned, as I am going from the oss-bite-size list. In future I will reference sponsor request table first, thanks for the heads-up! > > You also might want to check out an earlier thread on this > (http://www.opensolaris.org/jive/thread.jspa?messageID=159896𧂘), > specifically Mike Shapiro's comments on this: A very comprehensive write-up. I haven't as of yet looked into my options as to how I would approach this bug, I just know that it's functionality that I would definately like to see included, and this bug does look very interesting. Not one to attempt to re-invent the wheel, it may be better if I select another bug to work on, as I can see you have some history with this one..? cheers dsw.
[request-sponsor] Requesting sponsor for Bug ID 6518130
Hi - i'd like to work on the following bug. Bug ID: 6518130 Synopsis: pfiles(1) should list the processes listening on each socket Reported: SunOS 5.10 Full name: Danny Webster Username: dsw SCA number: OS0243 Cheers dan.
[request-sponsor] Requesting sponsor for Bug ID 6518130
On Mon, Apr 28, 2008 at 6:54 AM, danny webster wrote: > Hi - i'd like to work on the following bug. > > Bug ID: 6518130 > Synopsis: pfiles(1) should list the processes listening on each socket > Reported: SunOS 5.10 > Hi, Dan, I'm curious how you propose to solve this problem, as I've also requested a sponsor for this. (You can check this page to see if a bug already has a sponsor request: http://opensolaris.org/os/bug_reports/request_sponsor/. I'm more than happy to withdraw my request if you want this, though.) You also might want to check out an earlier thread on this (http://www.opensolaris.org/jive/thread.jspa?messageID=159896𧂘), specifically Mike Shapiro's comments on this: > I'm glad to see this: it's long overdue. The major issue I have though is > one of implementation: namely, it's way way too heavyweight to use the > global /proc hammer for this. This really needs to be implemented as > a kernel service that queries sockfs data structures or whatever > such that it is just a system call and a hash lookup, and not > globally stopping and starting every process. The problem with the /proc > approach is that it means that if you were to have a bunch of junior > admins run this in production a few times while learning the arguments > and trying to poke around at some problem, they could literally kill > performance of the box. Pgrab is *very* heavyweight: you're stopping > *every* thread of *every process*, kicking it off CPU, making it run > system calls, etc. This is fine for debugging one bad thing, but > it's like dropping an atomic bomb on a fully utilized busy machine. Chad Mynhier
