Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #39731 > unrolled thread

what thread or module is listening on a port?

Back to article view | Back to comp.lang.java.programmer

Contents

  what thread or module is listening on a port? Andreas Leitgeb <avl@logic.at> - 2022-02-23 12:37 +0000
    Re: what thread or module is listening on a port? Eric Sosman <esosman@comcast-dot-net.invalid> - 2022-02-23 10:51 -0500
      Re: what thread or module is listening on a port? Martin Gregorie <martin@mydomain.invalid> - 2022-02-23 16:51 +0000
    Re: what thread or module is listening on a port? Arne Vajhøj <arne@vajhoej.dk> - 2022-02-23 12:15 -0500
      Re: what thread or module is listening on a port? Andreas Leitgeb <avl@logic.at> - 2022-02-24 23:04 +0000
      Re: what thread or module is listening on a port? Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2022-03-19 12:47 +0100

#39731 — what thread or module is listening on a port?

Given a java process (that uses a couple of 3rd-party libs and stuff from
maven repo) and a TCP port number that this process is listening on (for all
interfaces), what options do I have for finding out, which "part" of the
process is responsible for the listening port?

Once I see, which of the umpty libraries did it, I can look for options
to either unconfigure it, bind to localhost, or at least understand it.

That's on Solaris (Unix).
$ netstat -aun | grep "54157.*LISTEN"     # gives me e.g:
      *.52634              *.*            xxx  54157 java 0      0  256000      0 LISTEN

The portnumber is in the >32k range and changes with each restart
of the process, thus apparently isn't itself configured.

When I telnet to the port, the connection is dropped after writing any 6
bytes to it. - maybe that rings a bell for some type of common service?

PS: Java here is Azul's "Zulu", openjdk version 1.8.0_252
     (in case it matters for further diagnostic tools available)

[toc] | [next] | [standalone]

#39732

On 2/23/2022 7:37 AM, Andreas Leitgeb wrote:
> Given a java process (that uses a couple of 3rd-party libs and stuff from
> maven repo) and a TCP port number that this process is listening on (for all
> interfaces), what options do I have for finding out, which "part" of the
> process is responsible for the listening port?
> 
> Once I see, which of the umpty libraries did it, I can look for options
> to either unconfigure it, bind to localhost, or at least understand it.
> 
> That's on Solaris (Unix).
> $ netstat -aun | grep "54157.*LISTEN"     # gives me e.g:
>        *.52634              *.*            xxx  54157 java 0      0  256000      0 LISTEN
> [...]
     Not a Java answer, but: Could you use dtrace to watch the
port creations as they go by and see which piece of code
instigates each one?  (My Solaris days are a distant memory
and my dtrace skills were never super-keen, but it seems to
me dtrace ought to be able to do the trick.)

     If the process opens ten thousand ports this could get
tedious, but still ...

-- 
esosman@comcast-dot-net.invalid
Look on my code, ye Hackers, and guffaw!

[toc] | [prev] | [next] | [standalone]

#39733

On Wed, 23 Feb 2022 10:51:06 -0500, Eric Sosman wrote:

> On 2/23/2022 7:37 AM, Andreas Leitgeb wrote:
>> Given a java process (that uses a couple of 3rd-party libs and stuff
>> from maven repo) and a TCP port number that this process is listening
>> on (for all interfaces), what options do I have for finding out, which
>> "part" of the process is responsible for the listening port?
>> 
>> Once I see, which of the umpty libraries did it, I can look for options
>> to either unconfigure it, bind to localhost, or at least understand it.
>> 
>> That's on Solaris (Unix).
>> $ netstat -aun | grep "54157.*LISTEN"     # gives me e.g:
>>        *.52634              *.*            xxx  54157 java 0      0 
>>        256000      0 LISTEN
>> [...]
>      Not a Java answer, but: Could you use dtrace to watch the
> port creations as they go by and see which piece of code instigates each
> one?  (My Solaris days are a distant memory and my dtrace skills were
> never super-keen, but it seems to me dtrace ought to be able to do the
> trick.)
> 
>      If the process opens ten thousand ports this could get
> tedious, but still ...

Try "lsof -p processid". Once the process has initialised and opened 
files and sockets etc, at the very least you'll get a list of what types 
of files have been opened and a fair idea of what each is attached to.

This is UNIX/Linux advice: I don't use Windows at all.
 

[toc] | [prev] | [next] | [standalone]

#39734

On 2/23/2022 7:37 AM, Andreas Leitgeb wrote:
> Given a java process (that uses a couple of 3rd-party libs and stuff from
> maven repo) and a TCP port number that this process is listening on (for all
> interfaces), what options do I have for finding out, which "part" of the
> process is responsible for the listening port?
> 
> Once I see, which of the umpty libraries did it, I can look for options
> to either unconfigure it, bind to localhost, or at least understand it.
> 
> That's on Solaris (Unix).
> $ netstat -aun | grep "54157.*LISTEN"     # gives me e.g:
>        *.52634              *.*            xxx  54157 java 0      0  256000      0 LISTEN
> 
> The portnumber is in the >32k range and changes with each restart
> of the process, thus apparently isn't itself configured.
> 
> When I telnet to the port, the connection is dropped after writing any 6
> bytes to it. - maybe that rings a bell for some type of common service?
> 
> PS: Java here is Azul's "Zulu", openjdk version 1.8.0_252
>       (in case it matters for further diagnostic tools available)

You could track all locations opening a socket.

Demo:

package february;

import java.io.IOException;
import java.lang.reflect.Constructor;
import java.net.ServerSocket;
import java.net.SocketImpl;
import java.net.SocketImplFactory;
import java.util.Arrays;
import java.util.stream.Collectors;

public class SocketTrace {
     public static void enableTrace() throws IOException {
         ServerSocket.setSocketFactory(new SocketImplFactory() {
             @Override
             public SocketImpl createSocketImpl() {
                 Exception e = new Exception();
                 StackTraceElement[] ste = e.getStackTrace();
                 String trace = Arrays.stream(ste).skip(4).map(v -> 
v.getClassName() + "." + v.getMethodName()).collect(Collectors.joining(" 
"));
                 System.out.printf("socket opened from %s\n", trace);
                 try {
                     Class<?> stdimpl = 
Class.forName("java.net.SocksSocketImpl");
                     Constructor<?> ctor = stdimpl.getDeclaredConstructor();
                     ctor.setAccessible(true);
                     return (SocketImpl) ctor.newInstance();
                 } catch(Exception ex) {
                     throw new RuntimeException(ex);
                 }
             }
         });
     }
     public static void m3() throws IOException {
         ServerSocket s = new ServerSocket(12345);
         s.close();
     }
     public static void m2() throws IOException {
         m3();
     }
     public static void m1() throws IOException {
         m2();
     }
     public static void main(String[] args) throws IOException {
         enableTrace();
         m3();
         m2();
         m1();
     }
}

output:

socket opened from february.SocketTrace.m3 february.SocketTrace.main
socket opened from february.SocketTrace.m3 february.SocketTrace.m2 
february.SocketTrace.main
socket opened from february.SocketTrace.m3 february.SocketTrace.m2 
february.SocketTrace.m1 february.SocketTrace.main

Arne

[toc] | [prev] | [next] | [standalone]

#39735

Arne Vajhøj <arne@vajhoej.dk> wrote:
> You could track all locations opening a socket.
> Demo:
>  [snip]

Thanks! That looks very promising - will try.


Eric & Martin: thanks for your hints, but unfortunately "lsof" no
longer works on Solaris 11.4 - apparently some API was changed, and
the lsof guys are not willing to bring back that thrown stick.

Even if it did, then it would probably still take some more tricks to
determine the thread-id and translate it into the names of the classes
that this thread is running....

[toc] | [prev] | [next] | [standalone]

#39742

On 23/02/2022 18:15, Arne Vajhøj wrote:
> On 2/23/2022 7:37 AM, Andreas Leitgeb wrote:
>> Given a java process (that uses a couple of 3rd-party libs and stuff from
>> maven repo) and a TCP port number that this process is listening on 
>> (for all
>> interfaces), what options do I have for finding out, which "part" of the
>> process is responsible for the listening port?
>>
>> Once I see, which of the umpty libraries did it, I can look for options
>> to either unconfigure it, bind to localhost, or at least understand it.
>>
>> That's on Solaris (Unix).
>> $ netstat -aun | grep "54157.*LISTEN"     # gives me e.g:
>>        *.52634              *.*            xxx  54157 java 0      0  
>> 256000      0 LISTEN
>>
>> The portnumber is in the >32k range and changes with each restart
>> of the process, thus apparently isn't itself configured.
>>
>> When I telnet to the port, the connection is dropped after writing any 6
>> bytes to it. - maybe that rings a bell for some type of common service?
>>
>> PS: Java here is Azul's "Zulu", openjdk version 1.8.0_252
>>       (in case it matters for further diagnostic tools available)
> 
> You could track all locations opening a socket.
> 
> Demo:
> 
> package february;
> 
> import java.io.IOException;
> import java.lang.reflect.Constructor;
> import java.net.ServerSocket;
> import java.net.SocketImpl;
> import java.net.SocketImplFactory;
> import java.util.Arrays;
> import java.util.stream.Collectors;
> 
> public class SocketTrace {
>      public static void enableTrace() throws IOException {
>          ServerSocket.setSocketFactory(new SocketImplFactory() {
>              @Override
>              public SocketImpl createSocketImpl() {
>                  Exception e = new Exception();
>                  StackTraceElement[] ste = e.getStackTrace();
>                  String trace = Arrays.stream(ste).skip(4).map(v -> 
> v.getClassName() + "." + v.getMethodName()).collect(Collectors.joining(" 
> "));
>                  System.out.printf("socket opened from %s\n", trace);
>                  try {
>                      Class<?> stdimpl = 
> Class.forName("java.net.SocksSocketImpl");
>                      Constructor<?> ctor = 
> stdimpl.getDeclaredConstructor();
>                      ctor.setAccessible(true);
>                      return (SocketImpl) ctor.newInstance();
>                  } catch(Exception ex) {
>                      throw new RuntimeException(ex);
>                  }
>              }
>          });
>      }
>      public static void m3() throws IOException {
>          ServerSocket s = new ServerSocket(12345);
>          s.close();
>      }
>      public static void m2() throws IOException {
>          m3();
>      }
>      public static void m1() throws IOException {
>          m2();
>      }
>      public static void main(String[] args) throws IOException {
>          enableTrace();
>          m3();
>          m2();
>          m1();
>      }
> }
> 
> output:
> 
> socket opened from february.SocketTrace.m3 february.SocketTrace.main
> socket opened from february.SocketTrace.m3 february.SocketTrace.m2 
> february.SocketTrace.main
> socket opened from february.SocketTrace.m3 february.SocketTrace.m2 
> february.SocketTrace.m1 february.SocketTrace.main
> 
> Arne
> 

That's bloody brilliant!

-- 
DF.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web