3

I'm receiving AttachNotSupportedException when trying to start a JFR recording. It was working normally, until now.

jcmd 3658 JFR.start maxsize=100M filename=jfr_1.jfr dumponexit=true settings=profile

Output:

3658:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
        at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
        at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
        at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)

What might be happening?

SO: Oracle Linux Server release 6.7

$ java -version
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
hbelmiro
  • 987
  • 11
  • 31
  • See [this question](http://stackoverflow.com/questions/26140182/running-jmap-getting-unable-to-open-socket-file). Make sure you run `jcmd` by the same user as Java process works under. Make sure `/tmp` directory is writable. Also `jcmd` won't work if target JVM is hung. – apangin Jan 17 '17 at 17:24
  • @apangin `jcmd` is being executed by the same user, /tmp is writable and the JVM isn't hung. – hbelmiro Jan 17 '17 at 17:30
  • Is Java process run under chroot or cgroups? – apangin Jan 17 '17 at 18:49
  • No. It isn't running under chroot or cgroups. – hbelmiro Jan 17 '17 at 22:07
  • Process ID could be wrong, attach mechanism could be disabled or something else... It's going to be a guess game without more analysis from your side. – apangin Jan 18 '17 at 14:27
  • Try running Java process with `-XX:+StartAttachListener` option. – apangin Jan 18 '17 at 14:27
  • Does `jcmd` create `.attach_pid1234` file? Does target process receive `SIGQUIT`? Does it print stacktraces in response to `jcmd`? Can you see `/tmp/.java_pid1234` socket created? – apangin Jan 18 '17 at 14:29
  • Does jstack or jstack -F work? Do you see `Attach Listener` thread in a thread dump? – apangin Jan 18 '17 at 14:34
  • Try with sudo. It worked for me. – Vitaly Sazanovich Aug 19 '22 at 19:49

3 Answers3

10

One of the probable reasons is that /tmp/.java_pid1234 file has been deleted (where 1234 is PID of a Java process).

Tools that depend on Dynamic Attach Mechanism (jstack, jmap, jcmd, jinfo) communicate to JVM through a UNIX domain socket created at /tmp. This socket is created by JVM lazily on the first attach attempt or eagerly at JVM initialization if -XX:+StartAttachListener flag is specified.

Once the file corresponding to the socket is deleted, tools cannot connect to the target process, and unfortunately there is no way to re-create communication socket without restarting JVM.

For the description of Dynamic Attach Mechanism see this answer.

Community
  • 1
  • 1
apangin
  • 92,924
  • 10
  • 193
  • 247
2

With personal experience... This problem also occurs in scenarios where the development environment is divided into partitions, and the partition where the operating system is located is different from the operating system partition. Example, operating system partition is EXT4 and the development environment partition is NTFS (where the JVM is). Problem occurs because you can not create a file "/tmp/.java_pid6024" (where 6024 is the PID of the java process). To troubleshoot add -XX: + StartAttachListener at the start of the JVM, or application server.

Leonardo Borges
  • 21
  • 1
  • when I added StartAttachListener, the jcmd did not return. I am only using root user to run the java process and jcmd, within rhel 7 in VirtualBox on windows 7 host. The pid file is getting created as expected. Even the file is getting created in /tmp/hsperfdata_root/ as expected. What could be the problem? – Prakash May 17 '18 at 16:57
2

Another possibility: your app is running under systemd with 'PrivateTmp=yes'. This prevents the /tmp/.java_pid1234 file from being found.

JeffT
  • 31
  • 3