[ Moving to networking-discuss and cross-posting to observability-discuss. ]
Summary: Discussion on a Solaris-native tool to determine what process is listening on a specified port. On 10/8/07, James Carlson <[EMAIL PROTECTED]> wrote: > Chad Mynhier writes: > > On 10/1/07, Chad Mynhier <[EMAIL PROTECTED]> wrote: > > > I'd like to request a sponsor for > > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6518130. > > > > > > 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: > > http://interstel.net/~mynhier/6518130.txt. > > 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: > > - 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.) > > - 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. > > - 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.) > > - 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. Agreed. > > - 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"? 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. I'll condense/paraphrase the following points for brevity: - Should the tool allow for arbitrary tests against transport layer state, rather than limiting it to "listening" and "established"? - What about raw sockets? - What about remote port numbers? - Are any tokens perhaps needed for "special" types of ports? - How would you search by IP address or addresses or subnets? - Would it be possible to search by a range of ports? - Does the proposed tool work with both TLI and sockets? > - 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. > > - There probably ought to be an mdb dcmd with a similar name and > equivalent functionality ("::pport"). Noted. > > - 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. Yes, the text is worded poorly in this case. > > - 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? Not as currently implemented, but I'd already considered adding that. > > - 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. Noted. > > - Nit: I'd prefer to see lower-case command line option letters > rather than upper-case, when possible. Noted. Thanks, Chad Mynhier _______________________________________________ networking-discuss mailing list [email protected]
