0

I have a Tomcat 9.0.60 Server running on OpenJDK 1.8.0 on Linux where a netstat -ltpn|grep java shows that it listens to more than the configured ports:

tcp        0      0 0.0.0.0:37917           0.0.0.0:*               LISTEN      50384/java          
tcp        0      0 10.100.0.188:39780      0.0.0.0:*               LISTEN      50384/java          
tcp        0      0 10.100.0.188:41415      0.0.0.0:*               LISTEN      50384/java          
tcp        0      0 0.0.0.0:34476           0.0.0.0:*               LISTEN      51139/java

(I removed all the configured ports from that list.)

So I think that several applications also opened "their own" sockets they listen to. I want to find out for each port, which of the Java threads is listening to, so I can then further find out the application and maybe if it is still required or just a leftover one of the devs forgot.

So far I tried to find out things with the VisualVM via a JMX connection, but did not get very far - probably because I'm not experienced enough.

Can you give me any hints - or maybe a complete solution - how I can find out the port to thread mapping please?

I don't need to automate this, it's more of a once-in-a-while manual job for documentation and checking.

cyberbrain
  • 3,433
  • 1
  • 12
  • 22
  • 1
    Are you conflating threads and processes? IIRC for `50384/java` the number `50384` is the process id, aka pid, which should correspond to the pid in `top` and similar. – Taylor Jul 12 '22 at 14:25
  • @Taylor: No, I'm not mixing that up. 50384/java is the PID of my Tomcat process - but that serves multiple applications with multiple threads - and my goal is to find out, which thread in that single process is listening to which port. From the threads I can do a thread dump and search further on, that shouldn't be a problem then. – cyberbrain Jul 12 '22 at 14:44
  • Ah, that makes sense. I had assumed embedded servlet container, but that's not the situation here. Thanks for clarifying. I would grab a thread dump (i.e. `kill -3 [pid]`), and look for threads in a listening loop. This may or may not give you the answer but would be the best next step imo. – Taylor Jul 12 '22 at 17:25

1 Answers1

0

If I was going to figure out what Java threads are listening, I would try the following things:

  1. Search the web application codebase for Java code that uses the ServerSocket class, and work backwards to what application code is responsible.

  2. Use jstack (or similar) to capture a snapshot of all of the Java thread stacks. Then scan them to find threads that are blocked in calls to the accept method.

  3. Use lsof with the -K option to get the thread ids for the llistening threads. Then use jstack and the technique described in How to obtain the JVM thread name/id through the known PID/TID to map the thread id to the Java thread.

Getting the Linux thread id for a Java thread in a Java thread involves using native code. But I don't think you need to get down to that level to get the information you need.

I'm puzzled as to why you are doing this. This kind of information is unlikely to help you debug the webapps. And if you are doing this because you suspect there is a security problem ... ask your Devs to "please explain" the unexpected TCP / listens on unexpected ports.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • The applications source code doesn't itself use sockets, but that comes probably from included 3rd party libs - and that's too much sourcecode to do a complete search there. And I don't want to debug the webapps with this, it just doesn't give me a good feeling to not even know the libs that the network listeners come from. But I will try to adapt your instructions and hope to fine a more generic way to identify "suspicious" threads. That link between TIDs and native thread IDs looks promising. ("Ask your Devs" - not all of them are still on the project) – cyberbrain Jul 12 '22 at 15:15