Chad Mynhier writes:
> On 10/1/07, Chad Mynhier <cmynhier at> wrote:
> > I'd like to request a sponsor for
> >
> >
> > Thanks,
> > Chad Mynhier
> > OS0124
> If anyone's curious about the details of my proposed solution, I've
> written up a fast-track which can be seen here:

In general, I think it's great to see this sort of extension.  It's
something we've needed for a long time.

Several comments on this:

  - I haven't seen any discussion about this on networking-discuss.
    I'd strongly recommend discussing the proposal there before
    proceeding with integration.

  - 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?)

  - 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

  - What privileges are required in order to use the utility?  How
    would ordinary users examine their own networking applications?

  - In order to integrate properly into Solaris, I believe that this
    tool should support at least the standard transport layers, and
    that means adding sctp.  Supporting just tcp and udp isn't enough.

  - 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.)

  - Is distinguishing between "established" and "listening"
    sufficient?  If you need to distinguish these at all, then why not
    allow for arbitrary tests against transport layer state?  (It
    would be quite nice indeed to obsolete the idea of grepping
    through the unstable output of "netstat" as a way of locating
    connections in a particular state.)

  - What about raw sockets?

  - What about remote port numbers?  Would it be possible to look at
    connections that have a given remote port connected, rather than
    just looking at the locally bound port number?

  - Are any tokens perhaps needed for "special" types of ports?  Could
    the tool distinguish between anonymous port bindings (kernel-
    chosen) versus explicit bindings?  How about the system's
    configured privileged port list?

  - How would you search by IP address or addresses or subnets?

  - Would it be possible to search by a range of ports?  For example,
    searching for open X window displays by looking for ports in the
    range 6000-6099.

  - Does the proposed tool work with both TLI and sockets, or is it
    sockets-only?  Some applications still do use TLI, and the
    existing pfiles command doesn't display them well at all.  Try
    running this command to see what I mean:

        # pfiles `pgrep rpcbind`

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

  - There probably ought to be an mdb dcmd with a similar name and
    equivalent functionality ("::pport").

  - Perhaps just a nit: The text seems to imply that there can be only
    one process listening on a given port.  That's not true.  If you
    have a process listening on a port, and you call fork(2), you'll
    then have two processes listening on the same port.  There are
    other ways for this to happen as well in certain contexts,
    including SO_REUSEADDR.

  - Nit: Would like to have a "-d" option, just like pgrep, so that
    the output can be used with "ps -p".

  - Nit: I assume that standard services(4) names can be used, right?

  - Nit: "-v" probably shouldn't mean "show process name," as it means
    "invert search criteria" for pgrep, and that'd be confusing for a
    ptools utility.  Instead, use "-l" if you need this feature.  If
    we had a "verbose" option, I think I'd prefer to see verbose
    details about the socket that's held open, rather than details
    about the process.

  - Nit: I'd prefer to see lower-case command line option letters
    rather than upper-case, when possible.

James Carlson, Solaris Networking              <james.d.carlson at>
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

Reply via email to