Chad Mynhier writes:
> On 10/8/07, James Carlson <james.d.carlson at sun.com> wrote:
> > Chad Mynhier writes:
> > > If anyone's curious about the details of my proposed solution, I've
> > > written up a fast-track which can be seen here:
> > > http://interstel.net/~mynhier/6518130.txt.
[...]
> > - The materials don't mention the canonical tool for this job --
> > lsof. Why is that? I'd think that at least a feature comparison
> > or some hint about where we're headed would be in order. (Is this
> > just a stop-gap effort until lsof can be integrated, or are we
> > looking to subsume all of that functionality over time? If so, is
> > being different from other UNIX and Unix-like operating systems to
> > our advantage?)
>
> The oversight was mostly accidental. I'll claim youth and
> inexperience. Or at least inexperience.
>
> I'd like to hear comments on the larger question, though -- is it
> worth replicating functionality that's already in lsof, or would it be
> a better use of time to work towards integrating lsof?
>
> (I realize that this isn't the first time this has been discussed, so
> ii might be better (if possible) to keep the discussion to whether
> it's worth writing a separate tool.)
I think there are a number of worthwhile questions to explore:
- Suppose you can integrate lsof someday. Will pport still make
sense at that point? If lsof is easy enough to use and produces
the desired results, it might not make sense to try to maintain
two tools for one task. Most likely, one will fall into
disrepair.
That means it makes more sense either as a stop-gap effort (to be
removed when lsof arrives), as a contingency plan (in case lsof
never arrives), or as an alternate (in case lsof will just be too
hard to use or inappropriate for some tasks).
I think figuring out which way we're going is somewhat important
here, as it dictates how much effort should be put into polishing
this tool. If it's just temporary, then it might be good enough
as is and we don't have to worry too much about the fit-and-finish
issues.
- Is there some broader direction here? I suggested a fews ways
that this could be useful, such as having ptools members that can
be composed together easily as filters. That might be enough to
justify it.
- What happens with Linux/*BSD compatibility? If this (like pfiles
before it) is seen as a "good enough" or "Solaris-like" way to
solve the lsof gap, does it mean we just never get lsof due to
lack of interest?
> > - Technically, how will it work? Does it iterate over all processes
> > in user space, attaching to each one, then iterate over all open
> > files, determining what sort of descriptor each one is? If so, is
> > that the right way to do this? (We've long desired to have a
> > "return list of process IDs bound on these ports" sort of query in
> > IP's kernel interface, as it's needed by at *least* lsof and
> > identd.)
>
> As currently written, it does just that. The implementation of
> 4616466 would make the implementation of this command fairly trivial.
I see. As Mike Shapiro has pointed out, that might be ok as a demo,
but it'd probably be a bad thing on a production system. Grabbing
every thread (or at least one thread in every process) is going to
hurt on large systems.
> > - What privileges are required in order to use the utility? How
> > would ordinary users examine their own networking applications?
>
> As the current implementation is the moral equivalent of "cd /proc &&
> pfiles *", a user would the same privileges necessary to do that. A
> user would be able to see information about the processes they can
> examine and would get no information otherwise. (I'm not sure which
> is worse, letting the user see a bunch of "permission denied" errors
> for the processes they can't examine or just failing silently.)
It's a hard question to answer. At least in the past, we've tried to
make sure that system management tools do *not* produce incorrect
answers, which is why the "process hiding" feature for ps is
relatively new. I'd point you to the discussion in CR 4991905, but it
looks like much of that happened in private. :-/
> > - It's also frequently necessary to look for processes holding open
> > an AF_UNIX socket. Could this tool eventually do that, or is it
> > only intended for use with AF_INET and AF_INET6? (Perhaps "pport"
> > isn't quite the right name.)
>
> There's no reason why this couldn't be extended to do so. Perhaps
> this should be "netgrep" rather than "pport"? Or "netuser", to
> parallel "fuser"?
I think it becomes oddly entangled (functionally) with fuser when you
include AF_UNIX behavior. Perhaps.
There are other objects here that are somewhat similar, so I'm really
not sure where the boundaries are. That's why I was asking you. ;-}
> Actually, this seems to be what you're implying in the following set
> of questions -- a tool to find the set of processes that match a set
> of criteria specific to networking. Given the scope of such a tool,
> I'd argue that it be separate from pgrep, but I could probably be
> convinced otherwise if there are strong feelings to the contrary.
Keeping it separate from pgrep's long list of options seems like a
sane choice to me.
The one issue I have there is with the overall system design. I'd
like to see how pgrep and this new tool can be used together to find
processes of interest. See below.
> > - For the long term: Does it make sense to have this functionality
> > separate from pgrep? They seem to be doing similar things.
> > Perhaps, with suitable pgrep additions, there could even be a
> > family of independent tools that each filter lists of process IDs
> > on various criteria. Consider something like this:
> >
> > # pgrep -U carlsonj | pport -p - 5000
> >
> > ... where the idea is to get a list of processes that I'm running
> > (using pgrep), and then use pport to winnow that list (read on
> > stdin via "-p -") down to just the processes with port 5000 open.
>
> See my comment about the scope of the proposed command WRT pgrep.
Maybe I'm not being clear enough about this.
Both pgrep and this new tool produce lists of processes that fulfill
some criteria. Having them work _together_ would make them even more
powerful. Here's another example of why I think this would be good:
# pgrep -v -U root | pport -p - 1-1023
... that would list the non-root processes that have a privileged port
open. Note that these are two separate tools, but ones that can be
convinced (with an added command line option) to cooperate.
Another tool in this category could be an "nfsuser" -- something that
could match processes with files open (or address space mapped on
files) from a given NFS server or with other such criteria.
It seems to me that a consistent way of filtering lists of PIDs would
be a good thing to have. Perhaps there's a better way of doing this,
though. (I'm sure comm(1) and some file descriptor trickery in ksh93
can do this ...)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
